x86: improve code generation for passing promoted structs

[CarolEidt]

A number of issues remain in the handling of promoted struct arguments (GT_FIELD_LIST) after PR dotnet/coreclr#7847:

• We currently push the fields in reverse order, which is what we want to do for pointer-sized fields. However, for smaller fields we should keep them in the list order so that we can push the first field in the slot as 32-bits, and then store the remaining fields.
• We don’t require the byte fields to be in byteable registers, but it would be nice if we could preference them that way. (The current mechanism for indicating preferences relates mostly to preferencing to another lclVar or tree node.)
• If we have sub-pointer-sized fields, we always allocate an internal register, even though we may not need it. One strategy, if any of the sub-pointer-sized fields are either tree temps or last-use lclVars:
  • For the first such field, require a register (i.e. don’t make it RegOptional). This register can then be also used as a temporary register to load up the remaining sub-pointer-sized fields.
  • For the first byte field, make it require a register – this may be the same as above, or in addition to. One could fine-tune this but it’s probably not really worth it.
• If we need to adjust the stack for padding or holes in the struct, we currently use a series of pushes of 0. We should consider whether 1) it would be better to generate a sub in some or all cases, and/or 2) we should use push eax has the legacy jit does. My concern with the latter was that I wasn't sure how careful we need to be about what eax might contain (if it's padding it isn't guaranteed to be zero, but not sure if it's safe to just push any arbitrary value).

category:cq
theme:structs
skill-level:expert
cost:medium
impact:small