https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617
Richard Biener changed:
What|Removed |Added
Target Milestone|12.2|12.3
--- Comment #16 from Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617
--- Comment #15 from Michael_S ---
(In reply to Richard Biener from comment #14)
> (In reply to Michael_S from comment #12)
> > On related note...
> > One of the historical good features of gcc relatively to other popular
> > compilers was absen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617
--- Comment #14 from Richard Biener ---
(In reply to Michael_S from comment #12)
> On related note...
> One of the historical good features of gcc relatively to other popular
> compilers was absence of auto-vectorization at -O2.
> When did you d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617
--- Comment #13 from Hongtao.liu ---
> so for the situation at hand I don't see any reasonable way out that
> doesn't have the chance of regressing things in other places (like
> treat loads from non-indexed auto variables specially or so). Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617
--- Comment #12 from Michael_S ---
On related note...
One of the historical good features of gcc relatively to other popular
compilers was absence of auto-vectorization at -O2.
When did you decide to change it and why?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617
--- Comment #11 from Michael_S ---
(In reply to Richard Biener from comment #10)
> (In reply to Hongtao.liu from comment #9)
> > (In reply to Hongtao.liu from comment #8)
> > > (In reply to Hongtao.liu from comment #7)
> > > > Hmm, we have speci
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2022-05-17
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617
--- Comment #9 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #8)
> (In reply to Hongtao.liu from comment #7)
> > Hmm, we have specific code to add scalar->vector(vmovq) cost to vector
> > construct, but it seems not to work here, gu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617
--- Comment #8 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #7)
> Hmm, we have specific code to add scalar->vector(vmovq) cost to vector
> construct, but it seems not to work here, guess it's because &r0,and thought
> it was load n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617
--- Comment #7 from Hongtao.liu ---
Hmm, we have specific code to add scalar->vector(vmovq) cost to vector
construct, but it seems not to work here, guess it's because &r0,and thought it
was load not scalar？
r0.1_21 1 times scalar_store costs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617
--- Comment #6 from Michael_S ---
(In reply to Michael_S from comment #5)
>
> Even scalar-to-scalar or vector-to-vector moves that are hoisted at renamer
> does not have a zero cost, because quite often renamer itself constitutes
> the narrowes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617
--- Comment #5 from Michael_S ---
(In reply to Richard Biener from comment #3)
> We are vectorizing the store it dst[] now at -O2 since that appears
> profitable:
>
> t.c:10:10: note: Cost model analysis:
> r0.0_12 1 times scalar_store costs 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617
--- Comment #4 from Michael_S ---
(In reply to Andrew Pinski from comment #1)
> This is just the vectorizer still being too aggressive right before a return.
> It is a cost model issue and it might not really be an issue in the final
> code just
14 matches
Mail list logo
