arsenm wrote: > with the PR pulled in (on top of LLVM's HEAD > [aadfba9](https://github.com/llvm/llvm-project/commit/aadfba9b2aa107f9cada2fd9bcbe612cbf560650)), > the compilation command is: `clang++ -cl-std=CL2.0 -emit-llvm -c -x cl -g0 > --target=spir -Xclang -finclude-default-header -O2 test.cl` The output LLVM > IR after the optimizations is:
You want spirv, not spir > note bitcast to i128 with the following truncation to i96 - those types > aren't part of the datalayout, yet some optimization generated them. So > something has to be done with it and changing the datalayout is not enough. Any pass is allowed to introduce any IR type. This field is a pure optimization hint. It is not required to do anything, and places no restrictions on any pass > > > This does not mean arbitrary integer bitwidths do not work. The n field is > > weird, it's more of an optimization hint. > > And I can imagine that we would want to not only be able to emit 4-bit > integers in the frontend, but also allow optimization passes to emit them. Just because there's an extension doesn't mean it's desirable to use them. On real targets, they'll end up codegenning in wider types anyway 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
