[llvm-commits] [RFC] Patch 1/3 for the native code compiler of Erlang

Yiannis Tsiouris gtsiour at softlab.ntua.gr
Mon Jun 25 14:50:09 PDT 2012


On 06/25/2012 11:14 PM, Duncan Sands wrote:
> Hi,
Hi Duncan,
>>> 2. I'm bit concerned about code like "+ bool isHipeCall = (F ?
>>> F->getCallingConv() == CallingConv::HiPE : false);"
>> What are exactly your concerns about it?
>
> it surely has to be wrong? I didn't look at the code in question, but it
> sounds like at the point of a call you are looking at details of the
callee.
> But it should always be possible to codegen a call correctly just from the
> declared type of the callee, the calling convention, the actual
arguments and
> any attributes they may have, without looking at the called function. That
> said, I may have completely misunderstood what this is about - but it looks
> like a big red flag.
Maybe I'm the one that misunderstood what you and Anton 're
suggesting/concerned about or misconceived the LLVM code, but i think
that that is exactly what i do: i use this "isHipeCall" condition to
verify that it is a Hipe CC callee in two different circumstances (one
to return the correct alignment size in "GetAlignedArgumentStackSize" of
X86ISelLowering.cpp and one in X86RegisterInfo.cpp in order to select
the correct TC register class for the X86 architecture according to HiPE
ABI). Grep-ing into my -rather trivial- patch should easily verify my
sayings! :-) My approach, i.e. just to check the called function's cc
for these things, is rather similar to GHC's CC (see, for example
"X86RegisterInfo::getCalleeSavedRegs").

Let me add that Jakob suggested in a previous email that i should check
for a null-pointer dereference before using "F" in "F->getCallingConv()".


Best,
Yiannis

-- 
Yiannis Tsiouris
Ph.D. student,
Software Engineering Laboratory,
National Technical University of Athens
WWW: http://www.softlab.ntua.gr/~gtsiour

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120626/9bebc090/attachment.html>


More information about the llvm-commits mailing list