[llvm-commits] [PATCH] Execution domain support for VMOV and VLDR

[Jakob Stoklund Olesen]

On Aug 31, 2012, at 6:58 AM, Tim Northover <t.p.northover at gmail.com> wrote:

> Hi,
> 
>> The transformation is safe if you can establish that the original instruction is already reading or writing the other lane. This will often be the case when feeding NEON instructions, since coalescing has folded an INSERT_SUBREG into the instruction. From you own test:
>> 
>>        %S2<def> = VMOVS %S0<kill>, pred:14, pred:%noreg, %D1<imp-def>
>> 
>> The %D1<imp-def> operand tells you that any data dependencies on the other lane are already threaded through this instruction.
> 
> I've not been able to come up with an entirely satisfactory solution
> to this. If I understand correctly, the above instruction wouldn't be
> eligible because D0 is not an implicit-use. I've got a patch that I
> believe is correct. Unfortunately with the patch in place I've been
> unable to get any domain switching to trigger for VMOVS (VMOVSR and
> VMOVRS conversions are still possible, and presumably VLDR though I
> haven't checked yet).
> 
> For now I'd suggest we revert the VMOVS change and apply the fix
> (assuming you find no problems with it) to VMOVRS and VMOVSR. I've
> attached the diffs to do this.
> 
> Let me know what you think.

It's probably best to revert the VMOVS change. There is also something hinky about the <undef> flags you're setting on the two VEXTD instructions.

The VMOVRS transform is fine since you're not widening any defs.

I think a safe fix for VMOVSR is:

 if (!MI->definesRegister(DDst, TRI) && !MI->readsRegister(DDst, TRI))
   break;

It would be interesting to know if that is good enough to cover the cases you care about, or if you will need to compute the liveness of the other lane.

/jakob