https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99520
--- Comment #6 from ktkachov at gcc dot gnu.org ---
FWIW the version in the initial comment is what appears in 525.x264_r in
SPEC2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99520
--- Comment #5 from Jakub Jelinek ---
Not sure it is worth bothering except making sure we don't miscompile valid
weird code.
BTW, for testing, one can also mix the |s and +s in the expressions randomly to
get the result.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99520
--- Comment #4 from ktkachov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
> Consider e.g.
> unsigned foo (unsigned x)
> {
> return (x<<24) + ((x<<8)&0xff) + ((x>>8)&0xff00) + (x>>24) +
> (((x&0xff00)<<16)>>8);
> }
> as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99520
--- Comment #3 from Jakub Jelinek ---
Consider e.g.
unsigned foo (unsigned x)
{
return (x<<24) + ((x<<8)&0xff) + ((x>>8)&0xff00) + (x>>24) +
(((x&0xff00)<<16)>>8);
}
as example that should not be optimized into __builtin_bswap32 (but should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99520
--- Comment #2 from Jakub Jelinek ---
Bet handling PLUS_EXPR next to BIT_IOR_EXPR in find_bswap_or_nop_1
and pass_optimize_bswap::execute could do the trick.
Though, I guess for PLUS_EXPR one needs stronger tests in
perform_symbolic_merge.
Becaus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99520
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
