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
[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 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.
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
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
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)
> + ((
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.
> 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
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
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,
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
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
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
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
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 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
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
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
18 matches
Mail list logo
