[llvm] r178438 - Cleanup PPC(64) i32 -> float/double conversion

[Jakob Stoklund Olesen]

On Apr 2, 2013, at 5:20 AM, Ulrich Weigand <Ulrich.Weigand at de.ibm.com> wrote:

> Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote:
> 
>>> Quasi-related thought, we should take a serious look at Jakob's
>> SPARC-64 patches (from yesterday). It seems that they have a very
>> similar 32/64-bit instruction identity issue to that in PPC, and
>> Jakob addresses this by adding i64 as a valid type on the 32-bit
>> register class, reusing the original 32-bit instructions (and just
>> adding additional patterns for the 64-bit cases).
>> 
>> Sounds promising indeed!  I think Ulrich is off for a holiday today; we
>> should check first whether he's worked on something similar already as
>> part of the asm-parser patches.  If not I'll definitely put it on my
>> list of things to investigate -- have wanted to be rid of that
>> duplication since I started on this project. ;)
> 
> No, I haven't done anything along those lines yet.
> 
> I certainly agree it would be good to remove the duplication …

For the PPC integer registers, it may not be so simple.

When a register bank can hold differently sized types, there are two valid modeling choices:

 1. Define sub-registers for each size, or

 2. Define register classes with identical register sets, but different spill sizes.

We've been using 2. for PPC floating point registers and x86's xmm registers for a while. X86 actually has a hybrid where xmm registers are used for 32, 64, and 128 bits while we define new ymm registers for 256-bit vectors.

If you use 1., you must use sub-register pseudo-instructions to convert between register sizes, otherwise you'll get copies with mismatched register sizes.

Unfortunately, 1. also requires you to duplicate the instruction set, which is why I went with 2. for the SPARC v9 extension.

Some things can't be modeled with register classes. For example, Windows functions preserve some xmm registers, but clobber the high bits of the corresponding ymm registers. There is no way to express that in a register mask without sub-registers.

/jakob