[LLVMdev] making a copy of a byval aggregate on the callee's frame

Robert Lytton robert at xmos.com
Thu Jul 4 11:36:49 PDT 2013

Hi - help!

I have read through previous threads on the subject of 'byval'  e.g.
and read through code (as best I can) but I am no wiser.

I am using the XCore target where the pointee data needs to be copied by the callee (not the caller).
        > I am not sure what this means though - when I generate code
        > from the LLVM assembly, do I need to do anything with byval?

        yes, the pointee needs to be passed by-copy, which usually means on the
        stack but could mean in a bunch of registers.

        > Either in the calling location or in the called function?

        The caller does the copy IIRC.  If you look at the .s file you should see
        it happening.

unfortunately does not help me.

There seems to be some disagreement if it should be done in clang or llvm.
Indeed I have hacked clang's CodeGenFunction::EmitFunctionProlog() and it works - but it is not nice.
BUT it seems most believe that it should be done within llvm using 'byVal'.

I have tried to follow the the 'byval' flag but am too ignorant to make any meaningful headway viz:
I tried adding to the XCoreCallingConv.td:
    CCIfByVal<CCPassByVal<0,4>>        // pushes pointer to the stack
But Have got stuck knowing if I can add the copy at this stage.
Is the pointee's details available or only the pointer's?
(Sorry if I have not dug deep enough to trace from pointer to pointee)

I also started to looked at the XCoreFrameLowering::emitPrologue()

Unfortunately, whilst stumbling around in the code is an interesting way to see the scenery, I am losing any sense of direction I may have had to start with!

Any input gratefully recieved - including key source files or the order in which things happen.
I'll try tracing through the calls (will -debug be enough) tomorrow.

thank you


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130704/63d96a1a/attachment.html>

More information about the llvm-dev mailing list