================
@@ -1,12 +1,14 @@
; This test aims to check ability to support "Arithmetic with Overflow"
intrinsics
; in the special case when those intrinsics are being generated by the
CodeGenPrepare;
-; pass during translations with optimization (note -O3 in llc arguments).
+; pass during translations with optimization (note -disable-lsr, to inhibit
+; strength reduction pre-empting with a more preferable match for this pattern
+; in llc arguments).
-; RUN: llc -O3 -mtriple=spirv32-unknown-unknown %s -o - | FileCheck %s
-; RUN: %if spirv-tools %{ llc -O3 -mtriple=spirv32-unknown-unknown %s -o -
-filetype=obj | spirv-val %}
+; RUN: llc -O3 -disable-lsr -mtriple=spirv32-unknown-unknown %s -o - |
FileCheck %s
----------------
AlexVlx wrote:
Well, I think that in this case @arsenm is on the money here: we should have an
IR->IR test in CodeGenPrepare wherein we ensure that for the SPIR-V target, the
optimisation triggers and the saturating intrinsics show up. Their correct
lowering is, as you say, handled someplace else. Correctly selecting / lowering
them should be independent of whether they were implicitly inserted by some
optimisation pass, or explicitly inserted by the user. Personally, I would
separate that change from this PR (as it's pretty unrelated), and merely
disable LSR in the existing test temporarily so as to not lose its coverage.
Thoughts?
https://github.com/llvm/llvm-project/pull/110695
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
