JIT: Store padding information in ClassLayout/ClassLayoutBuilder

[jakobbotsch]

• Rename StructSegments -> SegmentList
• Add ClassLayout::GetNonPadding to get the non-padding of a class layout. Computed lazily for CORINFO_CLASS_HANDLE backed layouts and saved ahead of time for custom layouts.
• Add ClassLayoutBuilder::AddPadding and ClassLayoutBuilder::RemovePadding
• Remove Compiler::GetSignificantSegments and switch uses to ClassLayout->GetNonPadding()

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[jakobbotsch]

FYI @AndyAyersMS... I don't expect this to get us much given that stack allocated arrays are never handled by physical promotion due to address exposure, and physical promotion is the only user of padding information (today).

I think we can change object stack allocation to create custom layouts for all cases without regressions after this change. That should allow us to remove getTypeForBoxOnStack and simplify the ClassLayout creation logic slightly (we should only see value classes for it now).

[AndyAyersMS]

Looks good for struct cases.

Seems like for arrays of structs with padding this may end up creating a lot of data that we may never look at?

[jakobbotsch]

Looks good for struct cases.

Seems like for arrays of structs with padding this may end up creating a lot of data that we may never look at?

True. We can have object stack allocation avoid marking any padding for arrays for now and reevaluate if/when we end up with something that would actually benefit from it.

Also seeing some significant TP regressions, likely from block layouts always allocating the padding information. Will change so that it's created lazily for the cases with no padding.

[jakobbotsch]

No diffs now. cc @dotnet/jit-contrib PTAL @AndyAyersMS