[PATCH] ARM testcase improvements

[Matthias Braun]

On Oct 8, 2013, at 8:20 AM, Renato Golin <renato.golin at linaro.org> wrote:

> On 7 October 2013 23:42, Quentin Colombet <qcolombet at apple.com> wrote:
> 0001:
> LGTM.
> 
> +1.
> 
> 
> 0002:
> Unless I am missing the semantic of CHECK-DAG, this seems wrong:
> +;CHECK-DAG: 	str	r0, [sp, #8]
> +;CHECK-DAG: 	add	r0, sp, #8
> How could a str-add sequence with a write-after-read dependency be semantically equivalent to a add-str with a read-after-write dependency?
> 
> If you're referring to the first change, I think it's up to add r0 + str r2, which could then be:
> 
> ;CHECK: 	str	r0, [sp, #8]
> ;CHECK-DAG: 	add	r0, sp, #8
> ;CHECK-DAG: 	str	r2, [sp, #12]
Yes I wanted the 3rd instruction being able to move between the first two. As FileCheck computes dependencies between [[Variables]] and enforces a correct order for -DAG checks I used a different solution in my updated patch:

+;CHECK-DAG:    str [[R0:r0]], [sp, #8]
+;CHECK-DAG:    add [[R0]], sp, #8
+;CHECK-DAG:    str r2, [sp, #12]

> 
> This also looks dangerous:
> 
> +; CHECK-DAG: vld1.32 {[[REG1:d[0-9]+]][0]}, {{\[}}[[BASE]]:32]
> +; CHECK-DAG: add [[BASE2:r[0-9]+]], [[BASE]], #4
> +; CHECK-DAG: vld1.32 {[[REG1]][1]}, {{\[}}[[BASE2]]:32]
> 
> one will define REG1 and the other will use, in this case, it's not possible for them to be in different order. If CHECK-DAG can deal with that and impose the correct ordering, than that's fine.
yes FileCheck will enforce deps.

> 
> Same here, with SOURCE and ADDR:
> 
> +; CHECK-DAG:  vst1.64 {d{{[0-9]+}}, d{{[0-9]+}}}, [r[[SOURCE:[0-9]+]]:128]
> +; CHECK-DAG:  add.w r[[ADDR:[0-9]+]], r[[SOURCE]], {{r[0-9]+}}, lsl #2
> +; CHECK-DAG:  vld1.32 {[[DREG:d[0-9]+]][], [[DREG2:d[0-9]+]][]}, [r[[ADDR]]:32]
> 
> In this case, it looks impossible to have it in any other order…
yep that’s whay I reverted that part.

Updated patch is attached to my answer to Quentin.

Thanks for the review,
	Matthias

> 
> 
> 0003:
> LGTM.
> 
> +1
> 
> cheers,
> --renato

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131010/549a82e2/attachment.html>