[llvm] [Utils][SPIR-V] Adding spirv-sim to LLVM (PR #107094)
Mehdi Amini via llvm-commits
llvm-commits at lists.llvm.org
Mon Sep 9 14:55:50 PDT 2024
Nathan =?utf-8?q?Gauër?= <brioche at google.com>,
Nathan =?utf-8?q?Gauër?= <brioche at google.com>,
Nathan =?utf-8?q?Gauër?= <brioche at google.com>,
Nathan =?utf-8?q?Gauër?= <brioche at google.com>,
Nathan =?utf-8?q?Gauër?= <brioche at google.com>,
Nathan =?utf-8?q?Gauër?= <brioche at google.com>,
Nathan =?utf-8?q?Gauër?= <brioche at google.com>
Message-ID:
In-Reply-To: <llvm.org/llvm/llvm-project/pull/107094 at github.com>
joker-eph wrote:
> Currently, the testing infrastructure for SPIR-V is based on FileCheck. Those tests are great to check some level of codegen, but when the test needs check both the CFG layout and the content of each basic-block, things becomes messy.
>
> Because the CHECK/CHECK-DAG/CHECK-NEXT state is limited, it is sometimes hard to catch the good block: if 2 basic blocks have similar instructions, FileCheck can match the wrong one.
>
> Cross-lane interaction can be a bit difficult to understand, and writting a FileCheck test that is strong enough to catch bad CFG transforms while not being broken everytime some unrelated codegen part changes is hard.
I have quite some concerns with this line of arguments: this seems to go against the way virtually **all** of LLVM is currently tested.
While this seems like a valuable discussion to have, I see this as a major departure from the current testing approach, and as such this needs a clear RFC on the Discourse forum about the kind of testing we expect in LLVM (unit-testing vs integration tests) and all the associated tradeoffs.
In the meantime, please don't consider this as a valid alternative to unit-test / FileCheck tests.
(if this RFC / discussion already happened and I missed it, then please just point me to the discussion :) )
https://github.com/llvm/llvm-project/pull/107094
More information about the llvm-commits
mailing list