https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81496
--- Comment #8 from Hongtao.liu ---
Similar as 48609
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81496
--- Comment #7 from Hongtao.liu ---
we have plenty of such issues which are related to ABI and middle-end, when
pass/return struct/complex/int128 as parameter and middle-end will push them to
stack and load it back, but the problem is that eith
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81496
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-08-15
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81496
--- Comment #5 from Jakub Jelinek ---
Strangely I've just today tried icc on
typedef int V __attribute__((vector_size (32)));
V
f1 (int a, int b, int c, int d, int e, int f, int g, int h)
{
return (V) { a, b, c, d, e, f, g, h };
}
with -O3 -ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81496
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81496
--- Comment #3 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #0)
> With -O2 -mavx{,2,512f}, we get on the following testcase:
>
> typedef __int128 V __attribute__((vector_size (32)));
> typedef long long W __attribute__((vector_si
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81496
--- Comment #2 from Jakub Jelinek ---
Maybe even better would be to emit vmovq %r1, %xmm0; vpinsrq $1, %r2, %xmm0;
vpinsrq $2, %r3, %ymm0; vpinsrq $3, %r4, %ymm0; but not sure how to achieve
that.
For another testcase:
typedef long long W __attr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81496
Jakub Jelinek changed:
What|Removed |Added
CC||kyukhin at gcc dot gnu.org,
