This is the mail archive of the
mailing list for the GCC project.
Re: Higher level RTL issues
- To: law at redhat dot com
- Subject: Re: Higher level RTL issues
- From: Daniel Berlin <dan at cgsoftware dot com>
- Date: Mon, 22 Oct 2001 11:36:36 -0400
- Cc: Jan Hubicka <jh at suse dot cz>, gcc at gcc dot gnu dot org
- References: <email@example.com>
> 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?
"My friend has a baby. I'm recording all the noises he makes so
later I can ask him what he meant.