[RFC, PowerPC] Initial fast-isel support for PPC64

[Bill Schmidt]

On Wed, 2013-07-17 at 09:56 -0700, Jakob Stoklund Olesen wrote:
> On Jul 16, 2013, at 7:19 PM, Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote:
> 
> > I don't think there's much we can do to make the no-r0 stuff a lot
> > better (item f), at least without disturbing the common machinery for
> > all targets.  There are a number of places where generic fast-isel
> > assumes a single register class for a given type, even when the target
> > has multiple classes that can work.  It seems the DAG-isel code is able
> > to unify such register classes to make sure we never use R0 for a
> > register lifetime containing a use that forbids R0; but fast-isel is too
> > myopic for that, so we have to fix it up somehow.
> 
> TableGen synthesizes a GPRC_and_GPRC_NOR0 register class representing the intersection of GPRC and GPRC_NOR0. If you use that intersection class, you shouldn’t have any problems with instructions that don’t accept R0.

The problem isn't with the register classes, but with how fast-isel's
table-gen machinery generates code from the instruction descriptions.
For a given type, it assumes one register class that fits that type
(seems to be the first one defined, in this case GPRC).  For most
automatically-generated expansions this works, but when R0 is a
forbidden register, we have to do some fixup to force it to use the
GPRC_and_GPRC_NOR0 class.  This is the slight ugliness that Eric doesn't
care for (nor do I, but it seems to be a necessity).

> 
> I’d recommend that your define the register class explicitly in the .td file instead of using TableGen’s synthetic name.

We can certainly do that, but I don't mind the auto-generated class,
which works well with the selection DAG code as-is.

Thanks,
Bill

> 
> Thanks,
> /jakob
>