https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #39 from Jakub Jelinek ---
Author: jakub
Date: Thu Feb 4 09:02:01 2016
New Revision: 233128
URL: https://gcc.gnu.org/viewcvs?rev=233128&root=gcc&view=rev
Log:
PR target/69454
* config/i386/i386.c (convert_scalars_to_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #38 from H.J. Lu ---
(In reply to Ilya Enkovich from comment #37)
>
> DImode spill/fill in 32-bit mode doesn't have to be 8-byte
> aligned. I think that was the question.
The alignment comes from GET_MODE_ALIGNMENT. Some targets
h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #37 from Ilya Enkovich ---
(In reply to H.J. Lu from comment #36)
> (In reply to Richard Biener from comment #35)
> > I wonder why LRA cannot spill using unaligned moves?
>
> We keep track precise alignment requirement. RA will use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #36 from H.J. Lu ---
(In reply to Richard Biener from comment #35)
> I wonder why LRA cannot spill using unaligned moves?
We keep track precise alignment requirement. RA will use
spill/fill the used part of vector registers. For GP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #35 from Richard Biener ---
I wonder why LRA cannot spill using unaligned moves?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
Markus Trippelsdorf changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #33 from H.J. Lu ---
(In reply to Ilya Enkovich from comment #32)
> (In reply to Uroš Bizjak from comment #31)
> > Maybe we can use HJ's patch from Comment #27 and communicate converted_insns
> > flag from convert_scalars_to_vector to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #32 from Ilya Enkovich ---
(In reply to Uroš Bizjak from comment #31)
> Maybe we can use HJ's patch from Comment #27 and communicate converted_insns
> flag from convert_scalars_to_vector to ix86_finalize_stack_realign_flags?
> The i_f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #31 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #28)
> Which will likely penalize even code where the stv pass wouldn't do anything.
> Isn't it better to just disable the stv pass if the stack isn't aligned
> enough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #30 from H.J. Lu ---
Try this one:
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index a03a515..c82883e 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3588,16 +3588,6 @@ convert_scalars_to_vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #29 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #28)
>
> Which will likely penalize even code where the stv pass wouldn't do anything.
In normal case it is a nop since the incoming stack is 128-bit
aligned.
> Isn't it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #28 from Jakub Jelinek ---
(In reply to H.J. Lu from comment #27)
> (In reply to Ilya Enkovich from comment #26)
> > (In reply to H.J. Lu from comment #25)
> > > Please add -mpreferred-stack-boundary=2 to your tests. Otherwise,
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #27 from H.J. Lu ---
(In reply to Ilya Enkovich from comment #26)
> (In reply to H.J. Lu from comment #25)
> > Please add -mpreferred-stack-boundary=2 to your tests. Otherwise,
> > you just remove a nop.
>
> Here is a test which cra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #26 from Ilya Enkovich ---
(In reply to H.J. Lu from comment #25)
> Please add -mpreferred-stack-boundary=2 to your tests. Otherwise,
> you just remove a nop.
Here is a test which crashes LRA with the path you proposed. Crash happe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #25 from H.J. Lu ---
(In reply to Ilya Enkovich from comment #24)
> Well, I'll try to just remove alignment code from STV and see what happens.
Please add -mpreferred-stack-boundary=2 to your tests. Otherwise,
you just remove a nop.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #24 from Ilya Enkovich ---
(In reply to H.J. Lu from comment #23)
> (In reply to Ilya Enkovich from comment #22)
> > (In reply to H.J. Lu from comment #21)
> > > In another word, STV needs 128-bit aligned stack only when it generates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #23 from H.J. Lu ---
(In reply to Ilya Enkovich from comment #22)
> (In reply to H.J. Lu from comment #21)
> > In another word, STV needs 128-bit aligned stack only when it generates
> > 12-bit vector instructions.
>
> STV never gene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #22 from Ilya Enkovich ---
(In reply to H.J. Lu from comment #21)
> In another word, STV needs 128-bit aligned stack only when it generates
> 12-bit vector instructions.
STV never generates such instructions. But RA may spill SSE re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #21 from H.J. Lu ---
(In reply to H.J. Lu from comment #20)
> (In reply to Ilya Enkovich from comment #19)
> > (In reply to H.J. Lu from comment #17)
> > > Do you have a testcase to show that you need to realign stack for STV?
> >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #20 from H.J. Lu ---
(In reply to Ilya Enkovich from comment #19)
> (In reply to H.J. Lu from comment #17)
> > Do you have a testcase to show that you need to realign stack for STV?
>
> Reproducer for this tracker is such test, right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #19 from Ilya Enkovich ---
(In reply to H.J. Lu from comment #17)
> Do you have a testcase to show that you need to realign stack for STV?
Reproducer for this tracker is such test, right?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #18 from H.J. Lu ---
(In reply to H.J. Lu from comment #17)
>
> Do you have a testcase to show that you need to realign stack for STV?
You can keep track alignment requirement in STV and replace
/* Conversion means we may have 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #17 from H.J. Lu ---
(In reply to Ilya Enkovich from comment #15)
> (In reply to Jakub Jelinek from comment #14)
> > Have you tried H.J's patch? If I understand it right, IMHO at least the
> > *mov_internal changes look desirable to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #16 from Jakub Jelinek ---
But it is for a relatively uncommon case (-mpreferred-stack-boundary lower than
default) and furthermore, you need to have something spilled to trigger it.
Hopefully the most commonly used regs in loops wil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #15 from Ilya Enkovich ---
(In reply to Jakub Jelinek from comment #14)
> Have you tried H.J's patch? If I understand it right, IMHO at least the
> *mov_internal changes look desirable to me after the recent changes
> where misaligne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #14 from Jakub Jelinek ---
Have you tried H.J's patch? If I understand it right, IMHO at least the
*mov_internal changes look desirable to me after the recent changes where
misaligned_operand matters even for pre-AVX, and the result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #13 from Ilya Enkovich ---
(In reply to Jakub Jelinek from comment #5)
> Already during the expansion TARGET_STV makes quite a big difference, won't
> just disabling the stv pass cause performance regression to -mno-stv?
There is a di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #12 from H.J. Lu ---
# git grep stack_realign_processed
shows how it is checked.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #11 from H.J. Lu ---
/* Nonzero if function stack realignment estimation is done, namely
stack_realign_needed flag has been set before reload wrt estimated
stack alignment info. */
bool stack_realign_processed;
/* Non
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #10 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #9)
> convert_scalars_to_vector (i.e. the stv pass) is before that though, it is
> inserted after combine, while ix86_finalize_stack_realign_flags is during
> pro_and_epilog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #9 from Jakub Jelinek ---
convert_scalars_to_vector (i.e. the stv pass) is before that though, it is
inserted after combine, while ix86_finalize_stack_realign_flags is during
pro_and_epilogue pass after RA.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #8 from H.J. Lu ---
After ix86_finalize_stack_realign_flags, there should be no stack
alignment changes. convert_scalars_to_vector shouldn't change stack
alignment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #7 from H.J. Lu ---
Created attachment 37468
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37468&action=edit
A patch
Here is a patch. Ilya, can you take care of this? Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
H.J. Lu changed:
What|Removed |Added
Status|REOPENED|NEW
--- Comment #6 from H.J. Lu ---
The STV p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #4 from Ilya Enkovich ---
(In reply to Jakub Jelinek from comment #3)
> I need additional -march=x86-64 to trigger this.
> I'd say either we have to pessimistically assume what the STV pass might be
> doing already during expansion, o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69454
--- Comment #3 from Jakub Jelinek ---
I need additional -march=x86-64 to trigger this.
I'd say either we have to pessimistically assume what the STV pass might be
doing already during expansion, or the STV pass would need to perform parts of
what
39 matches
Mail list logo
