Closed m-kurtenacker closed 1 year ago
Thanks for working on this!
My last status for the feature/port-cdl-fixes branch was that i could compile it but that it would fail to run with the classic "this option already registered" problem related to cl::opt
s and static initializers.. does this mean the branch is working for you? If so, what is your build config?
Just a hunch regarding the fastcc
issue: .. there may be a mismatch between call ABIs with fastcc
, the ABI sleef was compiled for may dffer from the target you are vectorizing/compiling for.
The cl::opt
issue seems to be related to LLVM_BUILD_LLVM_DYLIB and LLVM_LINK_LLVM_DYLIB build flags. If I have these enabled, I too see cl::opt
s being registered twice. My usual "fix" for that is to remove LLVM libraries being linked to rvTool in tools/CMakeLists.txt. Without LLVM_BUILD_LLVM_DYLIB enabled everything seems to work alright.
About fastcc
: I was trying to build sleef from source, but that didn't seem change anything about this issue. I have not seen this in release/14.x before.
Made a tentative fix for the dylib issue. Could you check whether https://github.com/cdl-saarland/rv/commit/340e5cf9b2358a5057578dafdbb7b46c62860d31 fixes the cl::opt on your end, too?
Regarding the fastcc
issue, cf LLVM LangRef: "The calling convention of any pair of dynamic caller/callee must match, or the behavior of the program is undefined. "
In the bitcode i looked into, calls to auto-vectorized SLEEF functions do not carry the fastcc
attribute cc but the function definitions do.
Fastcc and cl::opt issues should be resolved with the https://github.com/cdl-saarland/rv/commit/fda63d41fc037446f0e616d961c74693674189ed branch . @m-kurtenacker Please check that this works on your end too, then we can merge.
Another patch for structOpt, fixing for test_070: https://github.com/cdl-saarland/rv/tree/feature/port-cdl-fixes_rvtool-ldylib-patch
test_022 and test_067 are still failing. All others are clean. @m-kurtenacker Could you look into this?
I cherry-picked everything over to my branch. Only change I added was to also check for LLVM_LINK_LLVM_DYLIB. Everything but test_067 seems to be working on my side now.
fastcc for sleef functions causes all sorts of havoc. Not sure why though.I don't realy get why fastcc is a problem for sleef, but some tests fail if it is enabled. The results in these tests look as if parts of the code are skipped. e.g.:
here, vectorized versions of foo and bar would produce the same results. The subtraction is somehow ignored.