[llvm] b737f1a - [AArch64] Regenerate some test checks. NFC
David Green via llvm-commits
llvm-commits at lists.llvm.org
Mon Sep 13 06:00:15 PDT 2021
Hello
I've been slowly updating a lot of tests, yes. I've been doing it bit at a time, half expecting an email like this.
Can you explain why you have test case differences now? In my experience the register are not the part of the test sensitive to change, codegen is or ordering is. Or else the tests are not testing all that they should (and updating codegen tests by hand is not something we should be spending all our time on in 2021! The test scripts have been shown to work well elsewhere.)
I would expect downstream users to run the update scripts if needed, and already need to do that for other test cases? Although I'm a little surprised that little tests need updating. Are they using different registers, or is it some of the other checks that need adding? Some part of this neon-mul-div test?
The test this is targeting (although I do believe it to be beneficial in general) - is that we would like to start making the -mcpu=generic target include features that help any micro-architecture without hurting others, especially between bit-little machines. So for example it already enables fuse-aes as it is considered to be useful for most architectures. We are trying to extend that to use an in-order schedule (A55), under the pretext that it will help in-order cores that benefit from such things, without hurting out-of-order cores that can out-of-order schedule around any codegen differences. My understanding is that clang for any apple target sets -target-cpu=apple-a12 so shouldn't be affected.
Our experiments so far seem to show that is the case, that larger cores are not hurt by the change to use in-order scheduling. But it does involve updating ~300 failing tests, which is what led me to updating some of them to be more maintainable. There are still quite a few I am having to change manually, but at least having the most obvious tests autogenerated makes forward progress possible.
Thanks
Dave
________________________________
From: Florian Hahn <florian_hahn at apple.com>
Sent: 13 September 2021 11:37
To: David Green <David.Green at arm.com>; David Green <llvmlistbot at llvm.org>
Cc: llvm-commits at lists.llvm.org <llvm-commits at lists.llvm.org>
Subject: Re: [llvm] b737f1a - [AArch64] Regenerate some test checks. NFC
> On Sep 13, 2021, at 11:29, David Green via llvm-commits <llvm-commits at lists.llvm.org> wrote:
>
>
> Author: David Green
> Date: 2021-09-13T11:29:44+01:00
> New Revision: b737f1acf42807b6c791fc87763967d60bfc7ee3
>
> URL: https://github.com/llvm/llvm-project/commit/b737f1acf42807b6c791fc87763967d60bfc7ee3
> DIFF: https://github.com/llvm/llvm-project/commit/b737f1acf42807b6c791fc87763967d60bfc7ee3.diff
>
> LOG: [AArch64] Regenerate some test checks. NFC
>
> This regenerates some of the tests that had very-close-to-updated check
> line already, in order to make them more maintainable.
>
It looks like the tests intentionally did only check for targeted instructions and now they are much more fragile and will need updating more often. There are many cases were we now check for the full assembly, when the only interesting bits are a few generated instructions. Granted, updating them can now be done by running a script, but that still can lead to a lot of changes needing review + potential to cause downstream conflicts.
The changes test also now rely on precise register assignments, which can cause pain for downstream users.
Could you share the patch where this simplifies updating the tests drastically?
Cheers,
Florian
> Added:
>
>
> Modified:
> llvm/test/CodeGen/AArch64/arm64-neon-aba-abd.ll
> llvm/test/CodeGen/AArch64/arm64-neon-mul-div.ll
> llvm/test/CodeGen/AArch64/arm64-nvcast.ll
> llvm/test/CodeGen/AArch64/arm64-register-pairing.ll
> llvm/test/CodeGen/AArch64/arm64-setcc-int-to-fp-combine.ll
> llvm/test/CodeGen/AArch64/arm64-subvector-extend.ll
> llvm/test/CodeGen/AArch64/arm64-trunc-store.ll
>
> Removed:
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210913/9d28a658/attachment.html>
More information about the llvm-commits
mailing list