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

[Evan Cheng]

On Jun 29, 2010, at 9:09 AM, Jakob Stoklund Olesen wrote:

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

I agree with Jakob. There is the job of domain crossing fix up pass.

Evan

> 
> /jakob
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits