Constant propagation should preserve field sequences

[SingleAccretion]

This is a CQ-only issue. We can see cases where (local) constant propagation propagates known addresses of statics and loses field sequences for them. This causes VN to be more pessimistic about those addresses than is necessary.

Fixing this would require saving the field sequence alongside the constant itself in assertions. Unfortunately, currently there is no space available, so some refactoring would be required to make sure there would be no memory consumption regression from this change.

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

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

Issue Details

---

This is a CQ-only issue. We can see cases where (local) constant propagation propagates known addresses of statics and loses field sequences for them. This causes VN to be more pessimistic about those addresses than is necessary.

Fixing this would require saving the field sequence alongside the constant itself in assertions. Unfortunately, currently there is no space available, so some refactoring would be required to make sure there would be no memory consumption regression from this change.

Author:	SingleAccretion
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[EgorBo]

    struct AssertionDsc
    {
        optAssertionKind assertionKind;
        struct SsaVar
        {
            unsigned lclNum; // assigned to or property of this local var number
            unsigned ssaNum;
        };
        struct ArrBnd
        {
            ValueNum vnIdx;
            ValueNum vnLen;
        };
        struct AssertionDscOp1
        {
            optOp1Kind kind; // a normal LclVar, or Exact-type or Subtype
            ValueNum   vn;
            union {
                SsaVar lcl;
                ArrBnd bnd;
            };
        } op1;
        struct AssertionDscOp2
        {
            optOp2Kind kind; // a const or copy assignment
            ValueNum   vn;
            struct IntVal
            {
                ssize_t iconVal; // integer
#if !defined(HOST_64BIT)
                unsigned padding; // unused; ensures iconFlags does not overlap lconVal
#endif
                GenTreeFlags iconFlags; // gtFlags
            };
            union {
                SsaVar        lcl;
                IntVal        u1;
                __int64       lconVal;
                double        dconVal;
                IntegralRange u2;
            };
        } op2;

Memory layout:

1>class Compiler::AssertionDsc::AssertionDscOp1	size(16):
1>	+---
1> 0	| optOp1Kind kind
1> 4	| vn
1> 8	| SsaVar lcl
1> 8	| ArrBnd bnd
1>	+---


1>class Compiler::AssertionDsc::AssertionDscOp2	size(24):
1>	+---
1> 0	| optOp2Kind kind
1> 4	| vn
1> 8	| SsaVar lcl
1> 8	| IntVal u1
1> 8	| lconVal
1> 8	| dconVal
1> 8	| IntegralRange u2
1>	+---


1>class Compiler::AssertionDsc	size(48):
1>	+---
1> 0	| optAssertionKind assertionKind
1> 4	| AssertionDscOp1 op1
1>  	| <alignment member> (size=4)
1>24	| AssertionDscOp2 op2
1>	+---

Obvious things:

1. we don't need that much space to store iconFlags (currently, we waste 8 bytes on it while there are only 22 possible values and they can't be mixed. - 1 byte is enough (5 bits actually)
2. alignment member (x64 only?)