HuaHuaY commented on code in PR #51266:
URL: https://github.com/apache/arrow/pull/51266#discussion_r3975726905
##########
cpp/src/gandiva/engine.cc:
##########
@@ -183,6 +185,26 @@ void AddAbsoluteSymbol(llvm::orc::LLJIT& lljit, const
std::string& name,
llvm::cantFail(std::move(error));
}
+void AddNativeBoolZExtAttrs(llvm::Function& function) {
Review Comment:
@pitrou I have pushed a new commit to fix the CI failure. An optimization in
LLVM 23 exposed an issue in our code.
https://github.com/llvm/llvm-project/pull/178977
When the LLVM JIT calls a function compiled by GCC that takes a `bool`
argument, we inform LLVM that the parameter type is `i1`. Consequently, LLVM
doesn't zero out the upper bits of the argument without `zeroext` attr;
however, GCC assumes the upper bits of a `bool` are zero, resulting in the
generation of incorrect code.
LLVM 22 did not fail the tests because, when calculating the `i1` value, it
used the sequence `icmp ne (and X, 1), 0`, which happened to clear the high
bits of the register. However, after LLVM 23 optimized this process to `trunc X
to i1` in the mentioned PR, that side effect—which we relied upon—was
eliminated.
For example:
In GCC, `if(!bool)` may be compiled as `if(bool^1 != 0)`. LLVM calculates a
value of `3`, and then converts it to `(i1)true`.
- In LLVM 22, the value in the register is `1` due to `icmp ne (and 1, 1),
0`, and `1^1 != 0` evaluates to false.
- In LLVM 23, the value in the register is still `3`, because `trunc X to
i1` does not actually clear the high-order bits, and `3^1 != 0` evaluates to
true.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
