Re: Higher level RTL issues

[law at redhat dot com]

  In message <20011013112552.E29652@atrey.karlin.mff.cuni.cz>you write:
  > > 
  > > I know folks have heard me mention the idea of a higher level RTL from
  > > time to time.  I must apologize for not posting this earlier -- oh well,
  > > life goes on.  I must also apologize as this isn't 100% complete, but
  > > given that I haven't posted anything about it already and the fact that
  > > I'm going on vacation tomorrow, I figured I'd at least get this info out
  > > and let folks chew on it while I'm gone.
  > Nice to hear that there is progress on mid-RTL side.
  > Would be possible, after the vacation, to tell us more details about
  > the implementation (or even better commit it to the branch)?  
The details of the proof of concept are pretty simple.  Remember, we don't
have the automatic lowering code, just proof of concepts at this point.

For the embedded target I have a series of state variables which indicate
whether or not we're working with generic RTL, lowering from generic to
target RTL or working with target RTL only.

The backend has a set of generic patterns which are only available when the
state variable indicates that we are working with generic RTL.

The backend has a set of splitters which are only available when lowering
from generic to target RTL.

The original backend's patterns (target specific) are basically unchanged.

The state variables are twiddled in rest_of_compilation and there's a wee
bit of code to call split_insns to actually call the lowering splitters.

Finally there's a small amount of code to scan the RTL chain looking for
RTL constructs that we can't currently deal with in the SSA path 
(libcalls, assignments to subregs, etc).  If none of the "bad" things are
found, then we automatically run the SSA path.

There's really not enough interesting bits for the proof of concept
embedded port to post (not to mention the details of the chip are still
under NDA).


For IA64 things are a bit more interesting.  The port works as-is.  Why?

Well, first, ssa-ccp isn't quite as aggressive as it could be in terms of
replacing registers with constants.  The cases where it is aggressive happen
to be the cases that ia64 handles without modifications (similarly for the
dominator optimizations).  Removing the restrictions in those optimizers is
trivial once we've got automatic lowering code.

Second, comparisons/jumps are in a reasonably well defined form (no cc0 for
example and patterns don't have extra uses/clobbers).

So all you'd really need to play with this stuff is the code which scans
the RTL for certain problem constructs and automatically uses the SSA path
if no such problem constructs are found.



  > If I think about the concept, there are some parts that appears dificult
  > to me, such as how are the calls represented, or the string operations...
Calls are one of the interesting issues.  There's a whole rats nest of things
that need to be improved, but none which are strictly required at this point.
ie, we can tackle how calls are represented independently of the rest of the
lowering work.

First, there should be a phase which unnests calls at the tree level.  Nested
calls make the code in calls.c a freaking nightmare (all the stack slot
saving crap).

Second, we want a model where arguments are attached to the call and eventually
lowered to assignments to stack slots and argument registers.  I'm not sure
where it makes sense to lower these assignments yet.  The same applies for
the return value.

Third, we want to delay exposure and lowering of libcalls.  libcalls sequences
are a disgusting hack and cause as many problems as they solve.  The tricky
part is that we need to unnest potential libcalls at the tree level so that
we avoid all the stack slot saving BS when we lower from a simple "div"
instruction to a __divsi3 libcall (as an example).

I haven't tacked string operations.  But my gut feeling is that we leave them
as simple string operations at the generic RTL stage, then either lower them
to the target specific string op, a series of simple insns, or a libcall
as part of the overall lowering process.

jeff