Richard Biener <richard.guent...@gmail.com> writes: > On Fri, Jul 12, 2019 at 12:28 PM Richard Sandiford > <richard.sandif...@arm.com> wrote: >> >> Richard Biener <richard.guent...@gmail.com> writes: >> > On Fri, Jul 12, 2019 at 10:00 AM Richard Sandiford >> > <richard.sandif...@arm.com> wrote: >> >> >> >> This change is needed to avoid a regression in gcc.dg/ifcvt-3.c >> >> for a later patch. Without it, we enter CSE with a dead comparison left >> >> by if-conversion and then eliminate the second (live) comparison in >> >> favour of the dead one. That's functionally correct in itself, but it >> >> meant that we'd combine the subtraction and comparison into a SUBS >> >> before we have a chance to fold away the subtraction. >> >> >> >> Tested on aarch64-linux-gnu, aarch64_be-elf and x86_64-linux-gnu. >> >> OK to install? >> > >> > cfg_cleanup if it does, runs fast-dce after cleaning up the CFG so does >> > it make sense to do this in the caller instead? (and after removing the >> > live problem just in case dce tries to keep that updated?) >> >> I think that only happens with CLEANUP_CROSSJUMP, which we don't use >> here as things stand. But that could easily change in future, and yeah, >> doing it after removing the live problem would be better. >> >> So something like the attached? (Only lightly tested, but it does >> still fix the original problem.) > > Yeah, that works, too (I was originally thinking to simply put it after > the cleanup_cfg (0) call ...). > > Any reason you use 0x100 instead of 256?
Just trying to set a precedent for future flags. :-) Beyond 65536 I have to look it up. > If nobody objects this is OK. Thanks. Richard
