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

[Jakob Stoklund Olesen]

On Jun 29, 2010, at 8:11 AM, Rafael Espindola wrote:

> 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.

I agree that a register subclass (DPR_VFP2) is not going to work for completely separating two execution domains, and a set of register aliases is the way to prevent that.

But is it really necessary? We already have the NEONMoveFix pass to handle this issue. Maybe it just needs to get a bit better? The test case in question is a two-instruction function:

	vmov.f32 s3, s0
	vmov.f64 d0, d1

It should be possible to pick the correct vmov in that case, but I am not surprised NEONMoveFix got it wrong.

The SSEDomainFixPass does something very similar, and it is close to being target independent. I was planning to do that, and use it for both SSE and NEON, but I never got around to it.

What do you think? For NEON it is literally just a question of picking the correct move instruction, nothing else. A whole new set of registers with aliasing to the old ones seems like overkill.

/jakob