[llvm-commits] [patch] Mostly mechanical removal of getPhysicalRegisterRegClass.patch

[Rafael Espindola]

On 29 June 2010 10:54, Anton Korobeynikov <asl at math.spbu.ru> wrote:
> Hello, Jakob
>
>> This is a little worrying, but probably not your fault.
> Yes. This somehow seems to be a fallout from subreg indices unification.
>
> Basically, the problem is that currently we can easily have
> cross-domain switches while walking via subregs.
> Look, for example, into DPR_VFP2 regclass. This class is used for NEON
> code and thus all the stuff operates inside the NEON domain. It should
> not contain any SPR subregs since there are no 32-bit reg-reg moves in
> NEON (think about the core with VFP disabled, but not NEON).
>
> In fact, this was the only reason why this regclass does exist - to
> restrict the set of regs used for certain neon instructions.

I think we agreed on IRC. The issues is that the question "give me a
regclass for D0" is ambiguous. Is that the NEON one or the VFP one? If
we don't specify this, the existing DPR_VFP2 class is a valid answer
and gives the copy creation extra freedom.

Since there are cases where we care a lot about moves from neon to
vfp, we should make those explicit. I agree with Anton that what we
should do is

*) Declare the neon registers as independent entities from the vfp
registers (D0N, D1N, ...)
*) Declare the class of neon registers. This will not intersect with
the vfp register classes
*) Declare move instructions between the two (COPY_TO_REGCLASS?). This
will print just like a regular copy, but have a cost that reflects the
move from neon to vfp or the other way.

Check?

Should I revert the patch while we work on this?

> --
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State University
>

Cheers,
-- 
Rafael Ávila de Espíndola