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

[Jakob Stoklund Olesen]

On Aug 30, 2012, at 3:24 AM, Tim Northover <t.p.northover at gmail.com> wrote:

>> I'm OK with this change.
> 
> Thanks. VMOVS domains is in r162898.
> 
> Now, finally (with luck), I've attached an updated version of the
> VLDRS patch which passes on the alignment of a memoperand if it's
> available.

Thanks, Tim. The alignment fix looks good.

Unfortunately, there is a more serious problem with these transforms that I missed earlier; they break data dependencies in the other lane. This could lead to miscompilations when the late scheduler reorders instructions.

Consider this code:

  %s1<def> = foo
  %s0<def> = vldrs ...
  bar %s1

There is a read-after-write data dependency between foo and bar through %s0. Now transform vldrs:

  %s1<def> = foo
  %d0<def> = vld1ln ..., %d0<undef>
  bar %s1

The wider def establishes a dependency between vld1ln and bar, which is OK, but the %d0<undef> severs the data dependency from foo. That is the meaning of the <undef> flag.

Without the dependency, there is nothing stopping the scheduler from moving foo below bar.

A %s1<imp-use> operand can be used to establish a dependency between foo and vld1ln:

  %s1<def> = foo
  %d0<def> = vld1ln ..., %d0<undef>, %s1<imp-use>
  bar %s1

This will insert vld1ln in the dependency chain between foo and bar without breaking it.

You can't add a dependency on a value that isn't there, so you need to know that %s1 is live before you can add the <imp-use> operand.

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.

/jakob