[tree-ssa] RFC: Dropping INDIRECT_REF variables

[Diego Novillo]

On Wed, 2003-05-14 at 11:31, Timothy J. Wood wrote:
> On Wednesday, May 14, 2003, at 08:09  AM, Diego Novillo wrote:
> > - We disable the ability to treat non-aliased pointer
> >   dereferences as if they were variables.  We would lose the
> >   ability to do some optimizations like:
> 
>    Please forgive me if I'm way off base here, but one example on PPC 
> that your code snippet reminded me of was int->float conversion.
>
Actually, it's my fault.  I wasn't clear enough.  My proposal is to drop
support on the base framework, only.  INDIRECT_REFs would need to be
supported by other passes like SSAPRE.


> void convert(int *input, float *output, unsigned int count)
> {
>      while (count--)
>          *output++ = *input++;
> }
> 
>    both words of the double on the stack are written on each loop even 
> though the one 32-bit portion is always the same.  This store should be 
> hoisted outside the loop (in the degenerate case above this can by a 
> pretty big performance win).  I don't have a 3.3 compiler right now, 
> but on Mac OS X 10.2 (3.1-based):
> 
Well, we never get to this level of detail on trees.  The code you quote
above is not optimizable at the tree level:

foo (input, output, count)
{
  int T.1;
  float T.2;

  while (1)
    {
      count = count - 1;
      if (count == 0ffffffff)
        {
          goto <ULe70>;
        };
      T.1 = *input;
      T.2 = (float)T.1;
      input = input + 4B;
      *output = T.2;
      output = output + 4B
    };
  <ULe70>:;
}

There's nothing in that loop that could be hoisted out.  If we knew the
value of 'count' we could probably unroll the loop, but that's about it.

It's important to note that there are many details that are not exposed
in the tree IL.  Essentially, if you have a target specific optimization
problem, you won't be able to fix it at the tree level.  The
optimizations we do on the trees help indirectly, of course.


Diego.