> The BIT_AND_EXPR case is clearly correct for all possible values. The code > says that if the result of BIT_AND_EXPR is known to be a non-zero constant, > and one or both of the BIT_AND_EXPR arguments have known value ranges [0,1] > (or boolean or precision 1, not talking about those now), then that value > with the [0,1] range actually had to be 1, otherwise BIT_AND_EXPR result > would be 0. > > The BIT_NOT_EXPR case is different, ~0 is -1 and ~1 is -2. If an SSA_NAME > has [0,1] range, then BIT_NOT_EXPR of that will be [-2,-1]. If value is one > of those two, then with your today's patch the assumption will be correct, > 1 or 0. If value is some other one, which should hopefully happen only in > dead code that we haven't been able to optimize, then we'd replace > different values though.
I don't understand the last sentence: we'll precisely replace a bogus value, which we know is impossible given the [0, 1] range, by 0 or 1. -- Eric Botcazou