[llvm-dev] Fwd: Writing unit tests - how to test re-orderable blocks...

[LLVM Mailing List via llvm-dev]

We have a test that looks like this…

define void @array16_store() {
; CHECK-LABEL: array16_store:

; CHECK: ldi [[REG1:r[0-9]+]], 204
; CHECK: ldi [[REG2:r[0-9]+]], 170
; CHECK: sts int.array+3, [[REG2]]
; CHECK: sts int.array+2, [[REG1]]

; CHECK: ldi [[REG1:r[0-9]+]], 187
; CHECK: ldi [[REG2:r[0-9]+]], 170
; CHECK: sts int.array+1, [[REG2]]
; CHECK: sts int.array, [[REG1]]


; CHECK: ldi [[REG1:r[0-9]+]], 221
; CHECK: ldi [[REG2:r[0-9]+]], 170
; CHECK: sts int.array+5, [[REG2]]
; CHECK: sts int.array+4, [[REG1]]
 store i16 43707, i16* getelementptr inbounds ([3 x i16], [3 x i16]* @int.array, i32 0, i64 0)
 store i16 43724, i16* getelementptr inbounds ([3 x i16], [3 x i16]* @int.array, i32 0, i64 1)
 store i16 43741, i16* getelementptr inbounds ([3 x i16], [3 x i16]* @int.array, i32 0, i64 2)
 ret void
}



The issue I have is this test is unnecessarily fragile because the compiler can (and recently has) decided to reorder the blocks in a perfectly valid way.  For example:

; %bb.0:
	ldi	r24, 221
	ldi	r25, 170
	sts	int.array+5, r25
	sts	int.array+4, r24
	ldi	r24, 204
	ldi	r25, 170
	sts	int.array+3, r25
	sts	int.array+2, r24
	ldi	r24, 187
	ldi	r25, 170
	sts	int.array+1, r25
	sts	int.array, r24
	ret


The three blocks should be independent, it doesn’t matter whether it does the store to array+5 and array+4 first or last. What matters is that each block stays together, these instructions must stay together for example:
	ldi	r24, 221
	ldi	r25, 170
	sts	int.array+5, r25
	sts	int.array+4, r24

But that could come after the other two blocks or before them.



How can I write FileCheck conditions to test this? If they were single re-orderable lines, I could use CHECK-DAG for each, but I need the four lines of each block to stay together.

Can anyone offer advice?

Carl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190307/3f5355c7/attachment.html>