Re: midRTL: midRTL generation

[Jan Hubicka <jh at suse dot cz>]

>  In message <200201241626.LAA24566@makai.watson.ibm.com>, David Edelsohn 
> writes:
>  > 	If you mean that binary operations should generate idealized
>  > mid-level RTL directly without requiring named patterns in each machine
>  > description, I completely agree.
> I think Jan and I agree totally on that point.    In fact, what we're
> differing about is details about how to make that happen.
> 
> One approach is to change the tree->RTL conversion code to do things like
> gen_generic_addsi, gen_generic_movdf, etc.

With midlevel, this can be done at higher level using
gen_generic_binop/gen_generic_move as midlevel RTL should be symetric and
support same primitives for each mode.

Currently we even do have infrastructure for that at place, called
expand_binop/emit_move_insn/few other functions.  All we need to do is to tweak
these relativly low level codeged issues.

Of course there are side cases where this interface is bypassed.  One that come
into mind is gnerating special code such as calls or string oeprations or
machine specific code that do expand builtins or call conventions that may have
to be tweaked.
> 
> 
> The other is to separate the recognizers/expanders.  The result would be
> that we'd have a MD file for generic RTL.  That MD file (and its resulting
> recognizer) would be used exclusively until we want to lower generic
> RTL into target RTL.

I completely agree even at point we should have two MD files.  That way
we can keep the existing interface for recognizing insns and optimizers and
it is easy to do.
Only what I am not sure about is whether we want to have named patterns
interface for midlevel RTL that do overlap with lowlevel RTL named patterns.

(like it may make sense to use gen function for strmov pattern, as strmov
representation in midRTL may be complex, but then we can have "generic_strmov"
pattern that will later lower by expanding existing "strmov" named pattern.

Honza
> 
> Once we start lowering until end of compilation we would deal strictly
> with the target backend.
> 
> With this scheme, we don't have to build up new interfaces for generating
> RTL.
> 
> jeff
>