Delete the zero-offset field sequence map

[SingleAccretion]

In #68712 I promised that we'd delete the zero-offset field sequences. This change (finally, one could say) delivers on that promise.

There are still two scenarios where the root field sequence will have a zero offset:

1. Some statics accessed via helpers.
2. R2R-affected class fields.

Due to the fact the former cases are rare, this change represents them as ADD(baseAddr, 0 <field seq>), which requires minimal extra handling (just one special case in morph).

The latter cases are not handled in this change to minimize diffs. It is likely that, if/when I get to supporting them, an explicit annotation node will be used (similar to ARR_ADDR), however, for now, there is no need for it.

We have some diffs due to the usual consequences of more precise VNs (they are no longer "polluted" by zero-offset sequences.

[ghost]

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

Issue Details

---

In #68712 I promised that we'd delete the zero-offset field sequences. This change delivers on that promise.

There are still two scenarios we have where the root field sequence will have a zero offset:

1. Some statics accessed via helpers.
2. R2R-affected class fields.

Due to the fact the former cases are rare, this change represents them as ADD(baseAddr, 0 <field seq>).

The latter cases are not handled in this change to minimize diffs. It is likely that, if/when I get to supporting them, an explicit annotation node will be used (similar to ARR_ADDR), however, for now, there is no need for it.

We have some diffs due to the usual consequences of more precise VNs (they are no longer "polluted" by zero-offset sequences.

Author:	SingleAccretion
Assignees:	-
Labels:	area-CodeGen-coreclr, community-contribution
Milestone:	-

[SingleAccretion]

Libraries Test Run checked coreclr OSX x64 Debug failure is #70450.

@dotnet/jit-contrib

[jakobbotsch]

Love it! I will trigger some stress jobs.

[jakobbotsch]

/azp run runtime-coreclr jitstress, runtime-coreclr libraries-jitstress

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[jakobbotsch]

Most of the stress failures are #71748, but the arm32 libraries-jitstress failures look related to this or one of the recent changes:

Assert failure(PID 61 [0x0000003d], Thread: 74 [0x004a]): Assertion failed 'OperIs(GT_LCL_VAR, GT_LCL_VAR_ADDR, GT_STORE_LCL_VAR)' in 'System.Buffers.Binary.Tests.BinaryReaderUnitTests:SpanWriteAndReadBigEndianHeterogeneousStruct():this' during 'Lowering nodeinfo' (IL size 1323; hash 0x710360ec; FullOpts)

    File: /__w/1/s/src/coreclr/jit/gtstructs.h Line: 65
    Image: /root/helix/work/correlation/dotnet

[SingleAccretion]

Assertion failed 'OperIs(GT_LCL_VAR, GT_LCL_VAR_ADDR, GT_STORE_LCL_VAR)'

Taking a look.

[SingleAccretion]

Taking a look

In the dump we have STORE_LCL_FLD<float>(BITCAST<float>(ADD<int>)). On ARM, we presume all BITCASTs are multi-reg nodes, which ultimately leads us down the wrong path.

This is fallout from #71567, I have opened #71831 to track the fix.

[jakobbotsch]

This is fallout from #71567, I have opened #71831 to track the fix.

Thanks for taking a look, looks like this change should be fine to merge then.