Re: random thought - optimizer

[law at redhat dot com]

  In message <Pine.GSO.4.10.10107021038400.21161-100000@nile.gnat.com>you write
:
  > I think the front end should be responsible for setting an "aliased"
  > attribute if an object may be accessed through pointers.
Actually, I would go with the opposite.  Set a bit indicating that it is
known not to be aliased.  The trick then becomes how to propagate that
information and be able to map back from a MEM expression back to the
original object.

The only idea I've had in this space was to keep a pointer back to the tree
node, which seems rather expensive, but maybe it's not that big of an
issue.  I really don't know.

  > At the level of trees passed to the back end, and especially at RTL
  > level, there is no information anymore about "safe" pointer operations
  > generated by the front end, which do not cause objects to become non-local
  > or aliased. 
There's some tidbits of information, but certainly not enough for one to
know if an object is aliased without further analysis.


  > In some cases dataflow analysis could prove potentially aliased objects 
  > local and unaliased after all, but such extra analysis should be done 
  > in addition to the initial classification done by the front end.
The general design I've seen is the backend structures have pointers back
into the front-end structures or annotations to enable it to express
the memory operation at a higher level.

This is usually augmented with base pointer, underlying type, array dependence
and other similar analysis to provide a series of tests for disambiguating
memory references.

When talking to folks about this, the general rule is to not lose the
information provided by the front-end -- but that's apparently rather
hard in practice, which is what I guess leads to the propagation step
and secondary alias analyzers.

jeff