[CIR][CIRGen] Support OpenCL Vector Types #613
Conversation
seven-mile
force-pushed
the
opencl-vec-types
branch
from
7fb1234 to
ded43cc
Compare
seven-mile
force-pushed
the
opencl-vec-types
branch
from
ded43cc to
b47be43
Compare
|
Test cases improved. Tell me if I missed something! ; ) |
There was a problem hiding this comment.
(The free-function nits are in reference to https://mlir.llvm.org/deprecation/; please check all occurrences in this PR.)
|
Nice catch! I appreciate it. Updated. Removed test cases for |
[CIR][NFC] Arrange test cases [CIR][NFC] Use ArrayAttr for elts [CIR][NFC] Test store one element and make HLSL NYI [CIR][NFC] Add test for one element load line 687 of CIRGenExpr.cpp [CIR][NFC] Fix untagged values [CIR][NFC] Add test for extended-sized vec store for branch: line 755 in CIRGenExpr.cpp # Conflicts: # clang/test/CIR/CodeGen/vectype-ext.cpp [CIR][NFC] Add test for undefined position in odd-component vectors
seven-mile
force-pushed
the
opencl-vec-types
branch
from
8f01283 to
3531b74
Compare
| // CIR: %{{[0-9]+}} = cir.vec.create(%{{[0-9]+}}, %{{[0-9]+}}, %{{[0-9]+}}, %{{[0-9]+}} : !s32i, !s32i, !s32i, !s32i) : !cir.vector<!s32i x 4> | ||
| // LLVM: %[[#X1:]] = load i32, ptr %{{[0-9]+}}, align 4 | ||
| // LLVM-NEXT: %[[#X2:]] = load i32, ptr %{{[0-9]+}}, align 4 | ||
| // LLVM-NEXT: %[[#SUM:]] = add i32 %[[#X2]], 1 |
There was a problem hiding this comment.
If we look at how LLVM currently codegen for this, we get a add nsw instead of a plain add, see https://godbolt.org/z/xdevh38r8. There are probably other differences too.
I believe its not related to this specific PR, but to set expectations: whenever LLVM checks are written, that should not be done blindly, we should actually check it against what traditional (OG) codegen currently emits. If there are semantic differences, they ideally should be fixed as part of the PR, but if not, we should create an issue so someone else could take a look later.
I'll create an issue for this one, can you please go through the rest of the file and see if you can spot more differences and create issues for them? Thanks in advance!
There was a problem hiding this comment.
Many thanks for finding out this diff! I actually went through the final LLVM IR and compared them, but missed this overflow flag quite carelessly.
After a double check, I found the default index types used by two paths are different: i64 for CIR and i32 for Clang. But if user is using other types(like vec[x: i32 or i64]), in both paths, they will be preserved as is. This PR chose i64 because the previous works from @dkolsen-pgi have already done it. Since they are all self-consistent, I don't think it's a problem.
Nothing else special.
There was a problem hiding this comment.
Sounds good to me, thanks for double checking the rest!
Resolve llvm#532 . Support CIRGen of `ExtVectorElementExpr` that includes swizzle `v.xyx` and subscription `v.s0`.
Resolve llvm#532 . Support CIRGen of `ExtVectorElementExpr` that includes swizzle `v.xyx` and subscription `v.s0`.
Resolve llvm#532 . Support CIRGen of `ExtVectorElementExpr` that includes swizzle `v.xyx` and subscription `v.s0`.
Resolve llvm#532 . Support CIRGen of `ExtVectorElementExpr` that includes swizzle `v.xyx` and subscription `v.s0`.
Resolve #532 . Support CIRGen of `ExtVectorElementExpr` that includes swizzle `v.xyx` and subscription `v.s0`.
Resolve #532 . Support CIRGen of `ExtVectorElementExpr` that includes swizzle `v.xyx` and subscription `v.s0`.
Resolve #532 .
Support CIRGen of
ExtVectorElementExprthat includes swizzlev.xyxand subscriptionv.s0.