This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Loop optimizer issues


    Once we reach this point we can greatly simplify expr.c, calls.c and
    likely lots of other code that deals with expanding/optimizing
    arbitrarily complex tree nodes, 

I disagree with this.

It's often quite hard to expand a "complex" tree into a "simpler" tree.  Yes,
you have simpler *operations*, but the resulting tree can be quite complex.
If you go directly to RTL, you avoid these problems.

As an example, we currently don't support bit-packed arrays in our tree
languages.  Ada, however, needs it, so the front-end has a huge amount of
code to convert such references into "simpler" Ada constructs.  These involve
lots of boolean operations and calls to library functions.  (Try specifying
-gnatdg on a subprogram using it to see what I mean.)

On my "to do one of these years" list is to add code to the exp*.c files to
handle bit-packed arrays (we can already express it in the tree).

The major advantage of doing this is when tree-ssa is working.  But *not* if
tree-ssa does what the Ada front-end does and converts it to the lower-level
stuff before optimizing.

It's my understanding that the whole point of tree-ssa is to allow GCC to do
higher-level optimizations before the tree is transformed too far from the
source code.  This means that optimizations that deal with arrays (e.g., in
loops) could know they are arrays, which is not at all the case now since
they look nothing *like* arrays.  This will produce much better optimizations,
especially when they are used in loops.

On the other hand, there are important peephole-like optimizations that come
into play only once you've converted the array references into the
appropriate boolean operations (this is also the case, but less so, for
normal field references).

This way you get to do both: tree-ssa does the high-level stuff and the RTL
optimizers do the lower-level stuff.

I see a very natural symbiosis between the higher-level tree-ssa optimizers
and the low-level RTL optimizers and don't understand why you seem to feel
that the goal should be to lobotomize the latter.

Yes, it's important for the tree-ssa project to have language-independent
trees to make optimizations easier (like for RTL), but it seems to be that
attempts to transform trees too far away from things that have similar
semantics to the source compromise the main goals of that project.

To my mind, the benefits of tree-ssa are the existance of a higher-level and
more global optimizers.  They will also remove a lot of junk that the RTL
optimizers will no longer have to do with: this will both make them more
effective and speed them up.

There seems to be this idea that there's some "competition" between the
tree-ssa and RTL optimizers and I don't see it that way at all.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]