https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104582
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
Summary|Unoptimal code for __negdi2 |[11/12 Regression]
|(and others) from libgcc2 |Unoptimal code for __negdi2
|due to unwanted |(and others) from libgcc2
|vectorization |due to unwanted
| |vectorization
Priority|P3 |P2
Target Milestone|--- |11.3
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
With -O3 started with
r11-3204-gc9de716a59c873859df3b3e1fbb993200fce5a73
With -O2 most likely with
r12-4240-g2b8453c401b699ed93c085d0413ab4b5030bcdb8
Not sure if it is better not to vectorize it or be able to undo the
vectorization.
In particular in this case, *.optimized dump has:
_14 = {_1, _5};
_8 = VIEW_CONVERT_EXPR<__int128>(_14);
where
vector(2) long int _14;
I guess it depends on how _8 is then used, if it is going to be used in some
vector context, perhaps the above can be a win, but when the __int128 is
returned as __int128, on targets that return in a pair of registers that is
never beneficial, I bet if it is stored into memory, it will be hardly ever
beneficial etc.
