Re: Higher level RTL issues

[Jan Hubicka <jh at suse dot cz>]

> law@redhat.com writes:
> 
> >   In message <20011021194030.G12034@atrey.karlin.mff.cuni.cz>you write:
> >   > > 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 t
> >   > he
> >   > > 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.
> > What Richard and I discussed as a generic set of patterns that would be
> > included by all ports via a #include or similar mechanism in the md file.
> > 
> A minor issue i'm sure, but how much does this increase the running
> time of the gen* programs on the md files?
> Or has it not been done enough yet to be able to tell?

Perhaps this can be done at higher level and teach genrecog to generate separate
functions for the generic stuff as they should be never intermixed together
and we avoid expenses of increasing number of instructions attrtab and ohters
needs to handle (ignore).

Honza
> 
> > jeff
> > 
> 
> -- 
> "My friend has a baby.  I'm recording all the noises he makes so
> later I can ask him what he meant.
> "-Steven Wright