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 another 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, GCC may compile `if(!value)` as the equivalent of `if((value ^ 
1) != 0)`, assuming that a `bool` argument is normalized to `0` or `1`. Suppose 
a bitmap byte contains `3(0b11)` and LLVM extracts bit 0 as an `i1` value 
before passing it to a GCC-compiled function with a corresponding bool 
parameter.
   - With LLVM 22, code generation for `icmp ne (and 3, 1), 0` happened to pass 
the canonical value `1`, so `(1 ^ 1) != 0` evaluated to false.
   - With LLVM 23, this is optimized to `trunc 3 to i1`. The LLVM result is 
correctly `i1 true`, but without `zeroext`, the physical register passed to GCC 
may still contain `3`, so `(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]

Reply via email to