midRTL: midRTL generation

[law@redhat.com]

In message <20020124175924.GF2603@atrey.karlin.mff.cuni.cz>, Jan Hubicka writes
:
 > >  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.
Right.  However, I see this as more of a cleanup item that we can tackle
much later as part of an overall cleanup to the tree->rtl conversion
phase.


 > 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.
Right.  But as I've asked, please ignore this stuff initially.  I'm much
more concerned about getting the right framework in place for generating
generic rtl and lowering to target rtl than I am about dealing with the
oddball cases like string ops, calls, etc.

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

 > 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.
I don't see that the namespace overlap is a bad thing or a good thing
on its own. 

jeff