> If I remember correctly and read the cfgexpand.c comment > > /* For a promoted variable, X will not be used directly but wrapped in a > SUBREG with SUBREG_PROMOTED_VAR_P set, which means that the RTL land > will assume that its upper bits can be inferred from its lower bits. > Therefore, if X isn't initialized on every path from the entry, then > we must do it manually in order to fulfill the above assumption. */ > > you run into a similar situation but no, I don't think your patch is > really fixing this given SUBREG_PROMOTED_VAR_P is only true depending > on a condition (and not a data-dependence).
If the new pseudo is initialized with the above semantics on every possible path where it is used, then I think it's OK. > 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). SUBREG_PROMOTED_VAR_P is fundamentally a property of the inner pseudo and not of the SUBREG it is put on, hence... > (oh, and yes, I think SUBREG_PROMOTED_VAR_P is a dangerous thing, > but so is VRP info on SSA names as we've learned...) ...yes, it is delicate to deal with. -- Eric Botcazou
