[llvm-dev] MachineVerifier flagging calls to memcpy as part of setting up a call stack
Nagurne, James via llvm-dev
llvm-dev at lists.llvm.org
Thu Jun 10 14:09:31 PDT 2021
Hi all,
I have a question about how large objects passed as arguments by value are handled .
One way a target may handle a large object being passed by value is to memcpy the object into the stack before the call. This is seen in the LLVM regressions test suite as 2010-11-04-BigByval.ll
%big = type [131072 x i8]
declare void @foo(%big* byval(%big) align 1)
define void @bar(%big* byval(%big) align 1 %x) {
call void @foo(%big* byval(%big) align 1 %x)
ret void
}
On our downstream target, this test fails in the MachineVerifier. Lowering of the call to @foo creates a call to memcpy to copy %x onto the stack so that it's passed by value. This results in the following code:
ADJCALLSTACKDOWN (For call to @foo)
ADJCALLSTACKDOWN (For call to @memcpy)
call memcpy
ADJCALLSTACKUP (For call to @memcpy)
call @foo
ADJCALLSTACKUP (For call to @foo)
The verifier is specifically checking that each 'FrameSetup' (here, ADJCALLSTACKDOWN) is followed by 'FrameDestroy' (here, ADJCALLSTACKUP), with no intervening 'FrameSetup'. I thought this to be an issue with our implementation, but I then ran this example on the AArch64 target available on Compiler Explorer:
https://godbolt.org/z/j1veMhqdY
And saw the same error. My searches through the email list, docs, and bug list couldn't immediately find a reference to this test or error and how to avoid it or do it correctly. The only thing I can think of is hoisting the call to memcpy above the first FrameSetup instruction, but I don't think I understand enough about what these instructions are doing or why the MachineVerifier cares about such ordering. Is there a correct way to perform this operation to make the verifier happy?
Regards,
J.B. Nagurne
Code Generation
Texas Instruments
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210610/3b1c7890/attachment.html>
More information about the llvm-dev
mailing list