https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #13 from CVS Commits ---
The master branch has been updated by Segher Boessenkool :
https://gcc.gnu.org/g:e5502ae72f784470019de5850017ad0c87ffacef
commit r11-4805-ge5502ae72f784470019de5850017ad0c87ffacef
Author: Segher Boessenkool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #11 from CVS Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:025f434a87336e38bf5140fba2005081876aa911
commit r11-4731-g025f434a87336e38bf5140fba2005081876aa911
Author: Kewen Lin
Date: Thu Nov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #10 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #9)
> I'm not sure what you mean.
>
> vmrglb merges the vectors
> abcdefghijklmnop
> and
> ABCDEFGHIJKLMNOP
> to
> iIjJkKlLmMnNoOpP
>
> ... ah, I see what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #9 from Segher Boessenkool ---
I'm not sure what you mean.
vmrglb merges the vectors
abcdefghijklmnop
and
ABCDEFGHIJKLMNOP
to
iIjJkKlLmMnNoOpP
... ah, I see what you mean I guess.
So, use something else instead? How about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #8 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #7)
> There are vmrglb and vrghb etc.?
But these are only for low/high part separately, with mtvsrdd both low/high
parts (doubleword) have the values, we don't have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #7 from Segher Boessenkool ---
There are vmrglb and vrghb etc.?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #6 from Kewen Lin ---
(In reply to Kewen Lin from comment #5)
> (In reply to Segher Boessenkool from comment #4)
> > Yes, timing suggests there is some SHL/LHS flush.
> >
> > On p9 and later we can use mtvsrdd instead of mtvsrd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #5 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #4)
> Yes, timing suggests there is some SHL/LHS flush.
>
> On p9 and later we can use mtvsrdd instead of mtvsrd (moving two
> bytes into place at one), which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #4 from Segher Boessenkool ---
Yes, timing suggests there is some SHL/LHS flush.
On p9 and later we can use mtvsrdd instead of mtvsrd (moving two
bytes into place at one), which reduces the number of moves from
16 to 8, and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #3 from Richard Biener ---
very likely the byte stores and then the following vector load will also
trigger
STLF issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #2 from Kewen Lin ---
(In reply to Segher Boessenkool from comment #1)
> Is that actually faster though? The original has shorter dependency
> chains. Or is this to avoid some LHS/SHL?
Yes, I tested it with one constructed case,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
--- Comment #1 from Segher Boessenkool ---
Is that actually faster though? The original has shorter dependency
chains. Or is this to avoid some LHS/SHL?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96933
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
CC|
14 matches
Mail list logo
