> The runtime check assures that at runtime, the upper 32 bits of pseudo 104 > must be always 0 (in this case, in some other case could be sign bit > copies).
OK, as Richard pointed out, that's not sufficient if we allow... > The question is if it would be valid say for forward propagation to first > propagate (or combine) the pseudo 97 into the (subreg/s/v:SI (reg:DI 104) > 0), then hoisting it before the jump_insn 16, have the subreg optimized > away and miscompile later on. ...this to happen. So we could clear SUBREG_PROMOTED_VAR_P as soon as the SUBREG is rewritten, but this looks quite fragile. The safest route is probably not to use SUBREG_PROMOTED_VAR_P in this conditional context. > That means either that the hoisting pass is buggy, or that SUBREG_PROMOTED_* > is only safe at the function boundary (function arguments and return value) > and not elsewhere. I think that Richard's characterization is correct: "Note that likely SUBREG_PROMOTED_VAR_P wasn't designed to communicate zero-extend info (can't you use a REG_EQUIV note somehow?) but it has to be information that is valid everywhere in the function unless data dependences force its motion (thus a conditional doesn't do)." i.e. this also works for a local variable that is always accessed with the SUBREG_PROMOTED_VAR_P semantics. -- Eric Botcazou
