https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
--- Comment #31 from rguenther at suse dot de ---
On Wed, 28 Feb 2018, law at redhat dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
>
> --- Comment #27 from Jeffrey A. Law ---
> WRT c#21. There is a good paper from Click
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
Jeffrey A. Law changed:
What|Removed |Added
Target Milestone|6.5 |9.0
--- Comment #30 from Jeffrey A.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
--- Comment #29 from amker at gcc dot gnu.org ---
(In reply to Jeffrey A. Law from comment #28)
> BTW, ISTM that we need Bin to chime in on the complexity of improving this
> in IVOPTS -- ie, is it gcc-8 or gcc-9 material. If the latter, then we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
--- Comment #28 from Jeffrey A. Law ---
BTW, ISTM that we need Bin to chime in on the complexity of improving this in
IVOPTS -- ie, is it gcc-8 or gcc-9 material. If the latter, then we should
adjust the target milestone.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
--- Comment #27 from Jeffrey A. Law ---
WRT c#21. There is a good paper from Click on an integrated GVN/GCM/reassoc.
"Combining Analyses, Combining Optimizations" It was published in PLDI. I've
probably got a copy here if you want it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
--- Comment #26 from amker at gcc dot gnu.org ---
Note the testcase:
void timer_stop();
volatile long keepgoing = 0;
double hand_benchmark_cache_ronly( double *x, long limit, long *oloops, double
*ous) {
long index = 0, loops = 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
--- Comment #25 from amker at gcc dot gnu.org ---
(In reply to Aldy Hernandez from comment #23)
> (In reply to amker from comment #22)
>
> > > So my suggestion would be to see if you can make SLSR generate
> > > TARGET_MEM_REFs
> > > based on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
--- Comment #24 from rguenther at suse dot de ---
On Wed, 28 Feb 2018, amker at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
>
> --- Comment #22 from amker at gcc dot gnu.org ---
> (In reply to Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
--- Comment #23 from Aldy Hernandez ---
(In reply to amker from comment #22)
> > So my suggestion would be to see if you can make SLSR generate
> > TARGET_MEM_REFs
> > based on some common infrastructure with IVOPTs.
> Yes, I also believe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
--- Comment #22 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #21)
> One major flaw here is that IVOPTs does nothing on this loop because it
> doesn't find any induction variables. So basically this is highlighting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
Richard Biener changed:
What|Removed |Added
CC||amker at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
Aldy Hernandez changed:
What|Removed |Added
Target|i?86-*-*|i?86-*-*, x86-64
--- Comment #20 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
--- Comment #19 from Marc Glisse ---
(In reply to Aldy Hernandez from comment #16)
> It seems tree-ssa-reassoc.c avoids reassociating most non-bit expressions by
> design (because of signed overflows):
[...]
> So instead of whacking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
--- Comment #18 from Jeffrey A. Law ---
A couple more notes. It could also well be the case that reassociating in a
way that encourages lea could be good for x86, but bad for other targets.
I also suspect this is closely related to other BZs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
--- Comment #17 from Jeffrey A. Law ---
It could well end up being a case where we need to look to see if the
expressions are likely to CSE to determine which is better.
I'm not sure if reassoc has that kind of capability.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
Aldy Hernandez changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
--- Comment #15 from Aldy Hernandez ---
(In reply to Jeffrey A. Law from comment #14)
> I wonder if this could be addressed with a more reasonable address
> computation reassociation.
> ISTM that we associating as (x + (y + c)) which seems like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534
Jeffrey A. Law changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
18 matches
Mail list logo
