https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102540
--- Comment #8 from Andrew Macleod <amacleod at redhat dot com> --- > > > > It would probably resolve an entire class of things where we don't > > recognize an > > equivalence between a cast and a bitmask of equivalent precision. > > > > This would also mean the reverse would apply.. ie if we instead branched on > > _2 > > != 0 we would also understand that _6 will be non-zero. > > I believe tracking known zero/one bits in addition to a range is more > useful - would that help in this case? Thats in plan and what I first thought would fix it. Reflecting on this problem however, it would only help on the zero side where all the bits are known zero, but the non-zero property we are looking for can't be reflected by known ones or zeros.. Unfortunately I don't see how we can solve this particular problem by tracking known bit values.. there wont be any known 1s or 0s in a.0_1... just a particular bit pattern that cannot occur. Another option would be if I can get a cheap enough low-opt pass of evrp (also on my list) we could run it really early before things get rearranged and then run the higher levels later. Anyway, I'll keep thinking about this...
