Re: Higher level RTL issues

[Jan Hubicka <jh at suse dot cz>]

> 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.

I've imaginated that w/o patterns at all - just have some easy enought
definition of "correct RTL", to get rid of the optimizer trying to hit into
existing pattern, but this sounds sane too.
> 
> 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.
Good.
> 
[snip]
>   > 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
Actually the current calls.c code can do unnesting, but only for "real calls" it
can see in the tree, not libcalls that can happend suddenly during tree generation.

But for unnesting you don't need to modify the tree structure, just always generate
in a way to compute operands first and set to proper places later.
This unfortunately won't work well for structures that are better returned from
nested calls directly where they should resist when calling the outer functions.

This works on targets w/o fixed stack pointer, as i386 is very well.
> 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).
Agreed, but we need to track the nesting of libcalls inside calls somehow.
> 
> 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.
Sounds easy - it is not that dificult to represent them just approximately
in the RTL.  With generic patterns and splitters it can be easy to write
the pattern and splitter calling the expand_builtin beast.

Honza
> 
> jeff