https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93990
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Last reconfirmed| |2020-03-03
CC| |jakub at gcc dot gnu.org
Resolution|FIXED |---
Ever confirmed|0 |1
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I must say I can't really reproduce this, tried with -O3 r227270 (there is
expected worse code), r227271 (already good), r230000, r240000, r250000,
r260000, r270002, r280000, r10-6985 and all emit the same 4 instructions (addq,
adcq, movq and xorq) + ret, just the scheduling slightly varries over time.
Though, looking at your assembly, seems you are using -fstack-protector-all or
-fstack-protector-strong, with that option it indeed emits more code, but it
did already in r227271.
And the reason why we get worse code with one of -fstack-protector-{all,strong}
is that the stores by the builtin are done using alias set 0 and so RTL DSE
isn't able to remove the stores because it thinks they might alias with the
stack canary.
One way to fix this would be I'd say to use alias set of unsigned int for
unsigned long long (depending on what the builtin prototype is), and another
one, perhaps better long term, would be fold those builtins during gimple to
some another md builtin, perhaps with space in name to make it user
unaccessible, which would return a complex unsigned or complex unsigned long
long containing both results, so that we wouldn't have the addressable variable
during expansion at all and stack protector wouldn't need to mark anything
(unless there are other user vars that need it).
