https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
--- Comment #20 from Wilco ---
(In reply to Richard Henderson from comment #19)
> I wish that message had been a bit more complete with the description
> of the performance issue. I must guess from this...
>
> > ldr dst1, [reg_base1, reg_ind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
Richard Henderson changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
--- Comment #23 from Richard Henderson ---
(In reply to Jiong Wang from comment #21)
> Please check the documentation at
> http://infocenter.arm.com/help/topic/com.arm.doc.uan0015b/
> Cortex_A57_Software_Optimization_Guide_external.pdf, page 14,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
--- Comment #21 from Jiong Wang ---
(In reply to Richard Henderson from comment #19)
> (In reply to Jiong Wang from comment #16)
> > But there is a performance issue as described at
> >
> > https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00281.ht
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
--- Comment #22 from Richard Henderson ---
Author: rth
Date: Wed Mar 16 21:23:05 2016
New Revision: 234269
URL: https://gcc.gnu.org/viewcvs?rev=234269&root=gcc&view=rev
Log:
PR target/70048
* config/aarch64/aarch64.c (virt_or_elim_regno_p): N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
--- Comment #19 from Richard Henderson ---
(In reply to Jiong Wang from comment #16)
> But there is a performance issue as described at
>
> https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00281.html
>
> "this patch forces register scaling ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
--- Comment #18 from Jiong Wang ---
(In reply to Wilco from comment #17)
> (In reply to Jiong Wang from comment #16)
> I ran this modified patch through a few benchmarks and there are no
> regressions. The codesize of SPEC2006 reduces significant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
--- Comment #17 from Wilco ---
(In reply to Jiong Wang from comment #16)
> * for the second patch at #c10, if we always do the following no matter
> op0 is virtual & eliminable or not
>
> "op1 = force_operand (op1, NULL_RTX);"
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
--- Comment #16 from Jiong Wang ---
(In reply to Richard Henderson from comment #13)
> Created attachment 37911 [details]
> aggressive patch
>
Cool! Thanks very much for experimenting this thoughtful new aggressive
direction.
But there is a pe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
--- Comment #15 from Wilco ---
(In reply to Richard Biener from comment #14)
> The regression in the original description looks severe enough to warrant
> some fixing even if regressing some other cases.
Agreed, I think the improvement from Rich
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
--- Comment #14 from Richard Biener ---
The regression in the original description looks severe enough to warrant some
fixing even if regressing some other cases.
I agree it's the aarch64 maintainers decision what to do for GCC 6. But please
do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
--- Comment #13 from Richard Henderson ---
Created attachment 37911
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37911&action=edit
aggressive patch
Consider something like this, whereby we allow (sfp + scale + const)
as an address all th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
--- Comment #12 from Wilco ---
(In reply to Jiong Wang from comment #11)
> (In reply to Richard Henderson from comment #10)
> > Created attachment 37890 [details]
> > second patch
> >
> > Still going through full testing, but I wanted to post th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
--- Comment #11 from Jiong Wang ---
(In reply to Richard Henderson from comment #10)
> Created attachment 37890 [details]
> second patch
>
> Still going through full testing, but I wanted to post this
> before the end of the day.
>
> This updat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
Richard Henderson changed:
What|Removed |Added
Attachment #37886|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
--- Comment #9 from Richard Henderson ---
While I fully believe in CSE'ing "base + reg*scale" when talking about
non-stack-based pointers, when it comes to stack-based data access I'm
less certain about the proper approach.
All things work out "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
--- Comment #8 from amker at gcc dot gnu.org ---
(In reply to Richard Henderson from comment #6)
> Created attachment 37886 [details]
> proposed patch
>
> I agree -- at minimum virtual and eliminable frame registers ought to be
> special-cased.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
Jiong Wang changed:
What|Removed |Added
CC||jiwang at gcc dot gnu.org
--- Comment #7 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
Richard Henderson changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
--- Comment #5 from Wilco ---
(In reply to amker from comment #4)
> (In reply to ktkachov from comment #3)
> > Started with r233136.
>
> That's why I forced base+offset out of memory reference and kept register
> scaling in in the first place.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
--- Comment #4 from amker at gcc dot gnu.org ---
(In reply to ktkachov from comment #3)
> Started with r233136.
That's why I forced base+offset out of memory reference and kept register
scaling in in the first place. I think my statement still h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Target||aarch64
Status|
23 matches
Mail list logo
