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 RTL-opt
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 shoul
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 might
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
Am Sonntag, 17. April 2005 16:26 schrieb Daniel Jacobowitz:
> 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
> > remova
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 dec
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
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 t
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 res
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,
I think Roger simply mis-spoke because in his original message, he
said what you said: the important issue is having the alias
information available in RTL. Much (but not all: eg., SUBREG info) of
that information is best imported down from the tree level.
Well, paradoxical subregs are just a mess
> 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.
> Thi
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)
> + ((
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.
[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 this is not yet true for the
> following of jumps and m
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 cl
19 matches
Mail list logo
