This is the mail archive of the gcc-patches@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: [patch] for PR 18040


kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     The tree optimizers do better on simple operations, which is why we
>     have GIMPLE in the first place.  
>
> Sure, but this begs the question of how we define "simple" ..
>
>     In fact, some people have argued that we should be breaking up
>     _all_ chains of dereference operations so that the optimizers
>     can see better.
>
> The problem, however, is that the SSA-based optimizations operate mostly
> on *scalars*, so making more aggregate temporaries, which is what
> happens when you break up those chains, creates things that are hard to
> remove under the present optimization environment.
>
> Moreover, some of those temporaries will be of variable-size, which
> we don't currently support.

But this problem goes away if you start manipulating all the
aggregates by reference.  Then you only have scalar (pointer)
temporaries.  If that doesn't do a good job, then that's a different
(but easier to resolve) optimization deficiency.

In the cases where we can't manipulate components of aggregates by
reference because they are not addressable, well, maybe we ought to
cook up some kind of thing that makes them addressable for the tree
optimizers' purposes.

> ... what I was trying to get at is that at the level of generating
> RTL, we treat a chain of reference operators as if it were one
> operation, by merging all the offset calculations into one.

Sure, but this is decidedly _not_ the way the tree optimizers want to
think about it.  Where RTL requires something to be done a certain
way, we should not make that into a design constraint on trees; at
most, there might be an impedance mismatch to be resolved in the
expander.

> Indeed, I once made a proposal of having a "reference annotation"
> that would formalize that approach and, for each dereference
> operation, produce a variable that represented the cumulative offset
> up to that point.  If you do that, then the entire chain really *is*
> one operation for all purposes except loop optimizers, which will
> want to look at array references.

Hmm.  That might turn out to be equivalent to my handwavey suggestion
of inventing some way to make unaddressable things addressable for
tree purposes.  Do you have a pointer to that proposal?

zw


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