> Some of the combine simplifications (you obviously know that) work by
> "hoping" that the CLOBBER is simplified away. I don't think you can
> preserve all their power if you propagate NULL. In most cases you can
> replace CLOBBER with NULL, but I don't think that's possible everywhere.
Yeah
Richard Kenner wrote:
Yes, one possibility is to use a RTX hook for this too. By default you
would return NULL (and this would propagate up); in combine you could
override it to return the CLOBBER.
I really don't see why. Look at when combine calls the simplify routines now.
If they return z
> Yes, one possibility is to use a RTX hook for this too. By default you
> would return NULL (and this would propagate up); in combine you could
> override it to return the CLOBBER.
I really don't see why. Look at when combine calls the simplify routines now.
If they return zero, it uses the o
[trimming down the Cc list]
1) what to do with (clobber (const_int 0)). This should be not so much
of a problem thanks to validate_change, but I'd be weary of having such
CLOBBER rtx-en in REG_EQUAL notes!
Just return NULL. The philosophy of simplify_rtx is different from combine.
In the fo
> Actually, simplify-rtx.c now uses nonzero_bits and num_sign_bit_copies:
> these ask combine for the value in the case of pseudos, via the "RTL
> hooks" mechanism.
Right. That was certainly a step (and was discussed a while ago), but doing
it more globally would make it even easier.
> 1) what
Well before GCC 4.x there was an attempt that a few of us worked on to try to
move the algebraic simplifications from combine to simplify-rtx.c, just like
we put tree folding in fold-const.c. At that point, combine just becomes
"bookkeeping". The problem with that approach was what to do with
> Combiner is an older approach of code selection.
Combine can be considered both as code selection or optimization. Likewise,
CSE. In many cases, especially now that we have the tree optimizers, CSE
does more code selection (best choice of operand) than CSE. So you could say
that CSE and Com
The problem is that to use the modern approach you need another
description of insns (with one pattern - one machine insn relation)
in tree representation with given cost for the tree. And it is a
huge work to rewrite current machine descriptions even only for this.
This is not really necessa
On 2/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
Getting 0.5% and 11.5% slowness
(308sec vs 275sec for compiling SPECINT2000) does not seems reasonable
Just to be sure: Did you build with --disable-checking for both
compilers? I often find myself comparing compilers with checking
enable
On 2/13/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
...
I am only affraid that solution for faster infrastructure
(e.g. another slimmer data representation) might change the interface
considerably. I am not sure that I can convinince in this. But I am
more worried about 4.3 release and I r
David Edelsohn wrote:
Vladimir Makarov writes:
Vlad> I did investigate the current status of the infrastructure on future
Vlad> mainstream processor Core2 (> 11% slower compiler, worse code and bigger
Vlad> code size). That is the reason why I started this.
You do not
Steven Bosscher wrote:
On 2/13/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
> Why is it unacceptable for it to mature further on mainline like
>Tree-SSA?
>
>
Two releases one after another to avoid. No one real experiment to try
to rewrite an RTL optimization to figure out how def-us
> Vladimir Makarov writes:
Vlad> I did investigate the current status of the infrastructure on future
Vlad> mainstream processor Core2 (> 11% slower compiler, worse code and bigger
Vlad> code size). That is the reason why I started this.
You do not believe that this is a concern of
Paolo Bonzini wrote:
The problem is that to use the modern approach you need another
description of insns (with one pattern - one machine insn relation)
in tree representation with given cost for the tree. And it is a
huge work to rewrite current machine descriptions even only for this.
Th
On 2/13/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
> Why is it unacceptable for it to mature further on mainline like
>Tree-SSA?
>
>
Two releases one after another to avoid. No one real experiment to try
to rewrite an RTL optimization to figure out how def-use chain will work.
Vlad,
David Edelsohn wrote:
Vladimir Makarov writes:
Vlad> I am just trying to convince that the proposed df infrastructure is not
Vlad> ready and might create serious problems for this release and future
Vlad> development because it is slow. Danny is saying that the beauty of the
V
On 2/13/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
I am just trying to convince that the proposed df infrastructure is not
ready and might create serious problems for this release and future
development because it is slow. Danny is saying that the beauty of the
infrastracture is just in imp
I even have own tool for
this NONA http://cocom.sf.net . Although it might be a good research to
make it work on insns from diffrent BBs.
Of course instruction selection is usually done intra-BB. However, some
analyses that combine performs, such as nonzero_bits and
num_sign_bit_copies, ma
> Vladimir Makarov writes:
Vlad> I am just trying to convince that the proposed df infrastructure is not
Vlad> ready and might create serious problems for this release and future
Vlad> development because it is slow. Danny is saying that the beauty of the
Vlad> infrastracture is just in im
Steven Bosscher wrote:
On 2/13/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
Wow, I got so many emails. I'll try to answer them in one email in
Let us look at major RTL optimizations: combiner, scheduler, RA.
...PRE, CPROP,SEE, RTL loop optimizers, if-conversion, ... It is easy
to make
> Jeffrey Law writes:
Jeff> I think everyone would be best served if they realized none of this is
Jeff> personal -- it's about technical decisions in an effort to improve GCC.
GCC development is far from perfect. The recent model generally
seems to be effective, although there is pl
On Tue, 2007-02-13 at 12:14 -0500, Vladimir Makarov wrote:
> David Edelsohn wrote:
>
> > Do you realize how confrontational your emails sound? Have you
> >considered asking about the technical reasoning and justification instead
> >of making unfounded assertions? Do you want everyone to refu
David Edelsohn wrote:
Do you realize how confrontational your emails sound? Have you
considered asking about the technical reasoning and justification instead
of making unfounded assertions? Do you want everyone to refute your
incorrect facts point by point?
David, I am sorry if yo
On 2/13/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
Wow, I got so many emails. I'll try to answer them in one email in
Let us look at major RTL optimizations: combiner, scheduler, RA.
...PRE, CPROP,SEE, RTL loop optimizers, if-conversion, ... It is easy
to make your arguments look valid
Do you realize how confrontational your emails sound? Have you
considered asking about the technical reasoning and justification instead
of making unfounded assertions? Do you want everyone to refute your
incorrect facts point by point?
David
> Let us look at major RTL optimizations: combiner, scheduler, RA. Do
> we need a global analysis for building def-use use-def chains? We
> don't need it for combiner (only in bb scope),
Combine would work *far better* if it had some uniform data structure. For
one thing, that means it could
Wow, I got so many emails. I'll try to answer them in one email in
order not to repeat.
Mark Mitchell wrote:
I was not trying to suggest that DF is necessarily as sweeping a change
as TREE-SSA. Certainly, it's not a completely change to the
representation.
It is not sweeping change as Tree
> In general, I am agree with this. I am just opposing to the strong
> words "not allowed". I think it should be decided in each concrete case.
I agree that "not allowed" was a poor choice of words in a project
such as GCC and, although we, as a project, do tend to normally make
decisions one a
"Vladimir N. Makarov" <[EMAIL PROTECTED]> writes:
> I know some work is being done on incremental df analysis. It could
> decrease time for rescanning RTL between passes. Let us hope on this.
My understanding is that on dataflow-branch the DF information is now
fully incremental.
I don't real
On 2/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
On Sunday I had accidentally chat about the df infrastructure on
IIRC. I've got some thoughts which I'd like to share.
I like df infrastructure code from the day one for its clearness.
Unfortunately users don't see it and probably don'
Vladimir N. Makarov wrote:
>> However, my understanding (as someone who's not an expert on the DF code
>> base) is that, as you say, the new stuff is much tidier. I understood
>> the objective to be not so much that DF itself would directly improve
>> the generated code, but rather than it would
Mark Mitchell wrote:
Vladimir Makarov wrote:
On Sunday I had accidentally chat about the df infrastructure on
IIRC. I've got some thoughts which I'd like to share.
I like df infrastructure code from the day one for its clearness.
Unfortunately users don't see it and probably don't care abo
Steven Bosscher wrote:
On 2/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
I like df infrastructure code from the day one for its clearness.
Unfortunately users don't see it and probably don't care about it.
With my point of view the df infrastructure has a design flaw. It
extracts a lo
Richard Kenner wrote:
Vladimir Makarov writes:
Vlad> Especially I did not like David Edelhson's phrase "and no new
Vlad> private dataflow schemes will be allowed in gcc passes". It was not
Vlad> such his first expression. Such phrases are killing competition which
Vlad> is bad
> > Vladimir Makarov writes:
>
> Vlad> Especially I did not like David Edelhson's phrase "and no new
> Vlad> private dataflow schemes will be allowed in gcc passes". It was not
> Vlad> such his first expression. Such phrases are killing competition which
> Vlad> is bad for gcc. What if the
David Edelsohn wrote:
Vladimir Makarov writes:
Third, I am disappointed that you chose to make this argument
personal.
David, I really apologize to make it personal. We are all one community
and we are all thinking to make gcc a better compiler.
> Vladimir Makarov writes:
Vlad> Especially I did not like David Edelhson's phrase "and no new
Vlad> private dataflow schemes will be allowed in gcc passes". It was not
Vlad> such his first expression. Such phrases are killing competition which
Vlad> is bad for gcc. What if the new speciali
Vladimir Makarov wrote:
> On Sunday I had accidentally chat about the df infrastructure on
> IIRC. I've got some thoughts which I'd like to share.
>
> I like df infrastructure code from the day one for its clearness.
> Unfortunately users don't see it and probably don't care about it.
You're r
On 2/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
I like df infrastructure code from the day one for its clearness.
Unfortunately users don't see it and probably don't care about it.
With my point of view the df infrastructure has a design flaw. It
extracts a lot of information about RT
39 matches
Mail list logo
