On Apr 18, 2005 07:41 AM, Roger Sayle [EMAIL PROTECTED] wrote:
On Sat, 16 Apr 2005, Richard Kenner wrote:
Although, RTL expansion may introduce new loops, these tend to be
rare, and the expanders have all the information they need to
hoist/sink invariant expressions and
I take it from your comments, that you are in the camp that believes
that the sun has not yet set on the need for RTL optimizers. :-)
I'm actually in the camp that the sun will never set on the need for
some RTL optimizers. We'll be able to remove some of the most costly
of them and the
Unfortunately you appear to have little clue what you are really
talking about. So let me provide you with some loud feedback as well.
Please try to keep this discussion on a civil level!
I had greatly underestimated the importance of RTL alias analysis,
especially with
On Apr 18, 2005 02:51 PM, Richard Kenner [EMAIL PROTECTED] wrote:
Unfortunately you appear to have little clue what you are really
talking about. So let me provide you with some loud feedback as well.
Please try to keep this discussion on a civil level!
I am (for a change, maybe)
Please try to keep this discussion on a civil level!
I am (for a change, maybe) not the one who started making the
discussion uncivil.
I'm sorry, but in my opinion that doesn't matter. I don't call people
names or make personal attacks no matter what I'm responding to.
This
Well, paradoxical subregs are just a mess:
Agreed, but I wasn't talking about the paradoxical case.
optimizations on paradoxical subregs are better served at the tree
level, because it is just obfuscation of e.g. QImode arithmetic.
Not clear: I think this is a more complex issue.
On Mon, 18 Apr 2005, Paolo Bonzini wrote:
Roger proposed lowering 64-bit arithmetic to 32-bit in tree-ssa! How
would you do it? Take
long long a, b, c;
c = a + b;
Would it be
c = ((int)a + (int)b)
+ ((int) (a 32) + (int) (b 32)
+ ((unsigned int)
But it turned out that CSE around basic blocks (-fcse-skip-blocks) was
still a very useful thing to do (and it still was, when I looked at it
again a couple of weeks ago).
And I would *very much* like to know why! My view was always that any
global CSE at all should render it unnecessary
You seem to be confused. We've known *why* CSE does stuff that GCSE
doesn't catch for almost as long as we've had GCSE.
It's because CSE *doesn't just do CSE*! It does value numbering, and
a bunch of other things, which are not really implemented at the RTL
level as seperate
On Monday 18 April 2005 18:28, Daniel Berlin wrote:
The correct viewpoint is we shouldn't remove CSE until every *profitable*
transformation it makes is subsumed by something else.
Otherwise, you've started with the unproven assumption that every
transformation CSE makes is profitable.
Well,
On Mon, 2005-04-18 at 13:34 -0700, Dan Nicolaescu wrote:
[EMAIL PROTECTED] (Richard Kenner) writes:
The correct viewpoint is we shouldn't remove CSE until every
*profitable* transformation it makes is subsumed by something else.
And, as I understand it, the claim is that
Hi,
while lacking the deep insight into GCC internals most of you have, I'd never
the less like to ask you to be very prudent concerning the issue of removal
of seemingly unnecessary RTL optimizations.
In contrast to 32 bit targets, for 8 and 16 bit targets the RTL representation
possibly
On Sun, Apr 17, 2005 at 03:19:43PM +0200, Björn Haase wrote:
Hi,
while lacking the deep insight into GCC internals most of you have, I'd never
the less like to ask you to be very prudent concerning the issue of removal
of seemingly unnecessary RTL optimizations.
In contrast to 32 bit
On Sat, 16 Apr 2005, Richard Kenner wrote:
Although, RTL expansion may introduce new loops, these tend to be
rare, and the expanders have all the information they need to
hoist/sink invariant expressions and unroll/peel themselves.
I disagree. In order to make the proper
I seem to have inadvertantly annoyed Steven Bosscher on IRC,
so by way of an apology and explanation I thought I'd post my current
opinion and thinking on the optimizations performed by GCC's middle-end
both at the tree-level in the tree-ssa optimizers and at the
RTL-level in the exisiting
Although, RTL expansion may introduce new loops, these tend to be
rare, and the expanders have all the information they need to
hoist/sink invariant expressions and unroll/peel themselves.
I disagree. In order to make the proper decisions about merging givs
and chosing which giv
16 matches
Mail list logo
