Richard Biener <richard.guent...@gmail.com> writes: > On Mon, Jan 29, 2024 at 5:00 PM Richard Sandiford > <richard.sandif...@arm.com> wrote: >> >> Tamar Christina <tamar.christ...@arm.com> writes: >> > Hi All, >> > >> > Recently something in the midend had started inverting the branches by >> > inverting >> > the condition and the branches. >> > >> > While this is fine, it makes it hard to actually test. In RTL I disable >> > scheduling and BB reordering to prevent this. But in GIMPLE there seems >> > to be >> > nothing I can do. __builtin_expect seems to have no impact on the change >> > since >> > I suspect this is happening during expand where conditions can be flipped >> > regardless of probability during compare_and_branch. >> > >> > Since the mid-end has plenty of correctness tests, this weakens the backend >> > tests to just check that a correct looking sequence is emitted. >> > >> > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. >> > >> > Ok for master? >> > >> > Thanks, >> > Tamar >> > >> > gcc/testsuite/ChangeLog: >> > >> > PR testsuite/113502 >> > * gcc.target/aarch64/sve/vect-early-break-cbranch.c: Ignore exact >> > branch. >> > * gcc.target/aarch64/vect-early-break-cbranch.c: Likewise. >> >> OK I guess, since I agree that the "polarity" of the branch isn't really the >> thing that we're trying to test. But the fact that even __builtin_expect >> doesn't work seems like a bug. Do we have a PR for that? Might be worth >> filing one (for GCC 15+) if we don't. > > But that only should affect which edge is fallthru, not the "polarity" > of the branch, no?
Right, that's what I meant by "polarity". I should have used a proper term, sorry. The conditions in the patch are inverses of each other, but it seems like the choice between them should be predictable if the branch is very likely or very unlikely. Thanks, Richard
