Re: ARM/getting rid of superfluous zero extension

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

David and i have been talking about this for some time.

what is needed is a real global optimization algorithm.  my leaning is 
to make do it at the rtl level because that is where everything has been 
exposed.   but it would be a lot easier in ssa form.

The first step in my opinion is to ask the backend what kind of 
operations are expensive and what kinds of operations are cheap. for 
instance some risc machines can do comparisons at any mode and some only 
do them on the width of a register. also some machines have different 
costs associated with sign or zero extension.  I really think that you 
not only need to connect up the sources and syncs but you have to 
understand the space of what kind of transformations changes are going 
to be cheapest.
People do not seem to ask this kind of question at the tree level which 
is one of the reasons that i lean to doing it at the rtl level.

but the chain that goes from a load or some other operation that has a 
specific width output to the
sync that has a specific width input can be a long one and only 
something equivalent to ssa or dataflow is going to let you connect the 
true sources with the true syncs.

this is the problem with tom's patch.    One of the examples that i have 
seen is a loop that has di mode add of an index variable and (had) an si 
mode comparison to exit the loop.    However, later passes removed the 
si mode comparison because on the ppc it used the loop count 
instruction.    but the add of the index variable with sign extension 
remained because it was an index variable and so the value fed back into 
itself.

you are never going clean this up unless you do something global so that 
you can break the recurrence and see that there is no sync to that web 
that really needs the value to be si mode.

kenny

On 10/04/2012 06:16 PM, David Edelsohn wrote:
> On Thu, Oct 4, 2012 at 2:18 PM, Eric Botcazou <ebotcazou@adacore.com> wrote:
> > > Any suggestion about how I could avoid generating this zero_extension?
> > Redundant extensions have been a hot topic for some time.  The combiner should
> > catch the local easy cases, we have ree.c for the nonlocal easy cases and Tom
> > recently posted:
> >    http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00408.html
> > which should catch more complex cases.
> >
> > I guess someone should gather the various missed optimization cases, draw a
> > global picture of the situation and see how the various approaches could be
> > fitted together.
> Kenny already did that as part of the thread with Tom.  Tom's patch
> also is incomplete.
>
> - David