https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53652
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-12-27
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53652
Andrew Pinski changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53652
--- Comment #5 from Segher Boessenkool ---
It might work a lot better if it didn't have to load that all-ones vector
in a separate insn. Because it does, you need to do a 3->3 combination
(which we do not currently support) if you need to do the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53652
--- Comment #4 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #3)
> Ran into this again in context of PR91204, there is another case that isn't
> matched for a different reason:
> int a, b, c[64];
>
> void
> foo (void)
> {
> int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53652
Jakub Jelinek changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53652
--- Comment #2 from Jakub Jelinek 2012-06-14
10:23:31 UTC ---
Such a def_insn_and_split isn't going to work well, because the hw supported
alternative (xor with all ones vector) needs the vector constant loaded into
memory, which is much preferra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53652
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment #1
