--- Comment #67 from rguenth at gcc dot gnu dot org 2009-01-24 10:19
---
GCC 4.3.3 is being released, adjusting target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #65 from rakdver at gcc dot gnu dot org 2008-12-12 20:34
---
Subject: Bug 32044
Author: rakdver
Date: Fri Dec 12 20:32:47 2008
New Revision: 142719
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142719
Log:
PR tree-optimization/32044
*
--- Comment #66 from rakdver at gcc dot gnu dot org 2008-12-12 20:42
---
(In reply to comment #64)
I agree that the most practical short-term solution is to avoid transforming
the loop into a division.
However, I'm also interested in what we think the right long-term solution
--- Comment #64 from mmitchel at gcc dot gnu dot org 2008-12-11 17:37
---
I agree that the most practical short-term solution is to avoid transforming
the loop into a division.
However, I'm also interested in what we think the right long-term solution is.
I'm not convinced that our
--- Comment #51 from dsilvers at digital-scurf dot org 2008-12-10 15:49
---
I'd like to raise here that bug 38453 which was marked as a duplicate of this
is in fact an example not only of wrong optimisation, but of missed
optimisation as well.
The compiler emits the loop in the bug
--- Comment #52 from mmitchel at gcc dot gnu dot org 2008-12-10 17:11
---
Steven, thanks for your comments on this issue. I agree with Richard G. that
this is P2 -- but I also agree with you that it's a serious issue.
Unfortunately, Bugzilla doesn't want to show me the test case
--- Comment #53 from rakdver at kam dot mff dot cuni dot cz 2008-12-10
18:15 ---
Subject: Re: [4.3/4.4 regression] udivdi3 counterproductive, unwarranted use
Hi,
Re. comment #16:
Zdenek, do you remember which revision / patch removed the cost check?
rev. 122896
And do
you
--- Comment #54 from rakdver at kam dot mff dot cuni dot cz 2008-12-10
18:23 ---
Subject: Re: [4.3/4.4 Regression] final value replacement too aggressive for
e.g. targets with no native div/mod insns
Zdenek, it would certainly be helpful to have the original justification for
your
--- Comment #55 from steven at gcc dot gnu dot org 2008-12-10 21:27 ---
// This is the test case from PR38453.
// See comment #0 of that bug for further information:
// http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38453#c0
typedef struct
{
int lc;
int pb;
} bar;
void foo(bar
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #56 from steven at gcc dot gnu dot org 2008-12-10 21:44 ---
Re. comment #52:
I've pasted the test case in the audit trail here as plain text -- it's pretty
small and it shows the problem nicely. The issue is that with -Os, on all
targets, the line,
propsRes-lc = prop0;
--- Comment #57 from rakdver at kam dot mff dot cuni dot cz 2008-12-10
22:02 ---
Subject: Re: [4.3/4.4 Regression] final value replacement too aggressive for
e.g. targets with no native div/mod insns
I think Zdenek is right in comment #54: We should reincarnate
--- Comment #58 from rakdver at gcc dot gnu dot org 2008-12-10 22:55
---
(In reply to comment #56)
Re. comment #52:
I've pasted the test case in the audit trail here as plain text -- it's pretty
small and it shows the problem nicely. The issue is that with -Os, on all
targets,
--- Comment #59 from mmitchel at gcc dot gnu dot org 2008-12-11 00:14
---
Steven, Zdenek --
Is there any way to teach the compiler to use the ARM __aeabi_divmod routine,
which provides both the quotient and remainder? At least with -Os, that is
probably optimal. In other words, once
--- Comment #60 from steven at gcc dot gnu dot org 2008-12-11 00:27 ---
IMHO I the transformation to division is not fine. I would argue this is the
core issue in this problem report.
You are right that a combination of div and mod is quite common in real-world
code. Right now, GCC
--- Comment #61 from rakdver at kam dot mff dot cuni dot cz 2008-12-11
00:28 ---
Subject: Re: [4.3/4.4 Regression] final value replacement too aggressive for
e.g. targets with no native div/mod insns
Furthermore, if we want to generate the loop instead, are the alternatives
you're
--- Comment #62 from mmitchel at gcc dot gnu dot org 2008-12-11 00:42
---
I take Zdenek's point about the transformation from division to a loop being
profitable only if x is small. But, that might argue that if we see the loop,
we still transform it into the division form -- but with
--- Comment #63 from steven at gcc dot gnu dot org 2008-12-11 07:03 ---
Re. comment #62:
Transforming the code and adding notes to allow the compiler to undo the
transformation is not an option with the available infrastructure in GCC.
You'd have to add some kind of note (something
18 matches
Mail list logo
