optAssertionProp_Ind should eliminate GTF_EXCEPT better.

[sandreenko]

Consider a tree like:

[000189] -A-XG-------              |  |  +--*  COMMA     void  
[000184] -A-XG---R---              |  |  |  +--*  not important trees here
[000188] -A-X----R---              |  |  |  \--*  ASG       ref   
[000185] D------N----              |  |  |     +--*  LCL_VAR   ref    V20 tmp15        d:2
[000187] ---X--------              |  |  |     \--*  IND       ref   
[000186] ------------              |  |  |        \--*  LCL_VAR   byref  V25 tmp20        u:2 Zero Fseq[Syntax]
[000195] ---X--------              |  |  \--*  COMMA     void  
[000194] ---X--------              |  |     +--*  IND       int   
[000193] -------N----              |  |     |  \--*  ADD       byref 
[000191] ------------              |  |     |     +--*  LCL_VAR   byref  V25 tmp20        u:2
[000192] ------------              |  |     |     \--*  CNS_INT   long   8 Fseq[PrecedingInitializersLength] 

We access V25 through indirection twice, once to get its field [Syntax] at 0 offset and then to get [PrecedingInitializersLength] with 8 offset.

Obviously, the second indirection can't fail, so [000194] should be deleted, but the current implementation of optAssertionProp_Ind can see that because [000191] and [000186] have different value numbers, because one of them has Zero Fseq[Syntax] attached.

category:cq
theme:assertion-prop
skill-level:expert
cost:medium

[AndyAyersMS]

Marking as future for now.

@sandreenko is this something you're going to pursue?

[sandreenko]

@AndyAyersMS yes, but I am not sure that it will fit into 5.0, so I think it is ok to keep it as future for now.

[SingleAccretion]

Zero-offset sequences have been deleted in #71455, making this issue obsolete.