https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010
--- Comment #10 from Manolis Tsamis ---
(In reply to ptomsich from comment #9)
> (In reply to Manolis Tsamis from comment #0)
> > E.g. another loop, non canonicalized names:
> >
> > .L120:
> > ldr q30, [x0], 16
> > moviv29.2s,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010
--- Comment #9 from ptomsich at gcc dot gnu.org ---
(In reply to Manolis Tsamis from comment #0)
> E.g. another loop, non canonicalized names:
>
> .L120:
> ldr q30, [x0], 16
> moviv29.2s, 0
> ld2 {v26.16b - v27.16b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010
--- Comment #8 from Richard Biener ---
It's expected that SSA naming can affect code generation, there's no
"declaration order" as for VAR_DECLs we could ultimatively fall back to.
Ideally algorithms should not depend on particular ordering so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010
--- Comment #7 from ptomsich at gcc dot gnu.org ---
(In reply to Manolis Tsamis from comment #5)
> On of these happens to precede a relevant vector statement and then
> in one case combine does the umlal transformation but in the other not.
Plea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010
--- Comment #6 from ptomsich at gcc dot gnu.org ---
(In reply to Manolis Tsamis from comment #5)
> On of these happens to precede a relevant vector statement and then
> in one case combine does the umlal transformation but in the other not.
Plea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010
--- Comment #5 from Manolis Tsamis ---
Also, I further investigated the codegen difference in the second example (zip
+ umlal vs umull) and it looks to be some sort of RTL ordering + combine issue.
Specifically, when the we expand the RTL for t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010
--- Comment #4 from Manolis Tsamis ---
Hi Andrew,
Thank for your insights on this. Let me reply to some of your points:
(In reply to Andrew Pinski from comment #1)
> >The most important case I have observed is that the vectorizer can fail or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010
--- Comment #3 from Andrew Pinski ---
The first example (of assembly here) in comment #0 is extra moves due to the RA
not handling subreg that decent for the load/store lane. There are other bug
reports dealing with that. Why the SSA_NAMES being
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010
--- Comment #2 from Andrew Pinski ---
Note what I had found in the past it is not exactly SSA_NAMEs that cause the
difference but rather the RTL register pesdu # causes differences in register
allocation which was exposed from the different in o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010
Andrew Pinski changed:
What|Removed |Added
Blocks||53947
--- Comment #1 from Andrew Pinski
10 matches
Mail list logo
