[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