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

[Jakob Stoklund Olesen]

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

> Hi,
> 
>> But either way, the fact the the destination D-register is fully defined by
>> the original instruction should be enough. You can check
>> MI->definedRegister().
> 
> I'd basically come to the conclusion that a D-register <imp-use>
> wasn't necessary if there was an <imp-def> (it's good to hear you
> confirm it though!), but my question was more about the *source*. We'd
> want to transform:
> 
>  %S2<def> = VMOVS %S0<kill>, pred:14, pred:%noreg; %D1<imp-use,kill>,
> %D1<imp-def>
> 
> into (implicits omitted and exactly where the %D0 is may be wrong in
> this case. It's one of the sources):
>  %D1 = VEXT.32 %D1, %D0, 1, pred:14, pred:%noreg
>  %D1 = VEXT.32 %D1, %D1, 1, pred:14, pred:%noreg
> 
> Don't we have exactly the same dependency-chain problem with %D0 as
> with %D1: we can't add it <undef> and we can't add it implicitly
> unless we know it's live (i.e. locally, that it's already an
> <imp-use>).
> 
> Or have I still misunderstood the situation?

The <undef> flag cancels the data dependency for one operand, but you can still add another operand that establishes the data dependency for the sub-register:

  %D1 = VEXT.32 %D1, %D0<undef>, 1, pred:14, pred:%noreg, %S0<imp-use>

This is safe because you already know that %S0 is live. The <undef> flag itself doesn't sever other %D0 dependencies, it only affects the current instruction. It won't affect an %S1 dependency across the instruction. Only def operands do that.

The <undef> flags means: "This operand doesn't care what value this register has".

/jakob