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

via llvm-dev llvm-dev at lists.llvm.org
Fri Mar 8 11:49:19 PST 2019



> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Carl
> Peto via llvm-dev
> Sent: Thursday, March 07, 2019 5:44 PM
> To: llvm-dev
> Subject: [llvm-dev] Writing unit tests - how to test re-orderable
> blocks...
> 
> 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.

I would capture the text output to a file, and run FileCheck multiple times
on the same file, once for each group of instructions. You would need to give 
each block of CHECK lines its own prefix, but that's a small thing.

But I would second the observation that even if different orders are valid,
the compiler's behavior should be deterministic, aside from patches that
change the ordering for a specific reason. This kind of breakage ought to
be unusual, and if it's not, that's likely a bug that should be fixed
instead of you working around it in your test.
--paulr

> 
> Can anyone offer advice?
> 
> Carl
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


More information about the llvm-dev mailing list