On Sat, May 3, 2025 at 4:42 PM Andrew MacLeod <amacl...@redhat.com> wrote: > > > On 5/3/25 07:41, Richard Biener wrote: > > On Sat, May 3, 2025 at 12:39 AM Andrew MacLeod <amacl...@redhat.com> wrote: > >> On trunk I'll eventually do something different.. but it will be more > >> invasive than I think is reasonable for a backport. > >> > >> The problem in the PR is that there is a variable with a range and has a > >> bitmask attached to it. We often defer bitmask processing, the the > >> change which triggers this problem "improves" the range by applying the > >> bitmask when we call update_bitmask. (PR 119712) > >> > >> The case in point is a range of 0, combined with a bitmask that says the > >> '1' bit must be on. This results in an UNDEFINED range since its > >> impossible. this is rarely a problem but this particular snippet of > >> code in IPA is tripping over it because it has checked for undefined, > >> and then created a new range by combining the [0, 0] and the bitmask, > >> which we turn into an UNDEFINED.. which it isn't expected. and then > >> it asks for the type of the range. > >> > >> As Jakub points out in the PR, this is effectively unreachable code that > >> is being propagated. A harmless fix would be to check if the result of > >> applying the bitmask results in an UNDEFINED value and to simply > >> replace it with a VARYING value. > >> > >> WE still reduce the testcase to "return 0" and no more failure. > >> > >> bootstraps on -x86_64-pc-linux-gnu with no regressions. > >> > >> If this is acceptable, I will push it to trunk, then also test/verify > >> for the GCC15 and 14(?) branches and check it in there. > > LGTM. IPA CP might want to either avoid looking at the type > > for UNDEFINED or track it separate from the value-range, not > > sure where it looks at the type of a range. > > > > Richard. > > > It appears they don't track undefined at al? l... but thats just a > cursory glance.
It probably isn't very useful to IPA CP propagate UNDEFINED. > On trunk. I think I'll adjust it next week and put the type into the > UNDEFINED range.. I have a functioning patch now. I think its too > pervasive and not really enough of an issue to do that on the release > branches > > It'll solve a few of these kinds of things when they pop up, and allow > us to properly do an invert () operation on VARYING and UNDEFINED, > which we have discussed before. > > Andrew >
