[LLVMdev] [PATCH][RFC] Add llvm.codegen Intrinsic To Support Embedded LLVM IR Code Generation

Yabin Hu yabin.hwu at gmail.com
Sat Apr 28 04:17:34 PDT 2012


Hi Tobi,

2012/4/28 Tobias Grosser <tobias at grosser.es>

>        Each call to the intrinsic has two arguments. One is the LLVM IR
>>        string. The other is the name of the target architecture. When
>>        running with tools like llc, lli, etc, this intrinsic transforms
>>        the input LLVM IR string  to a new string of assembly code for
>>        the target architecture firstly. Then the call to the intrinsic
>>        is replaced by a pointer to the newly generated string. After
>>        this, we have in our module
>>
>>
>>    Is the Arch parameter to llvm.codegen really needed?  Since codegen
>>    happens when lowering the intrinsic, the target architecture must be
>>    known.  But if the target architecture is known, then it should be
>>    available in the triple for the embedded module.
>>
>> Yes. It is better that the target data is set correctly in the embedded
>> module. It is the user's responsibility to do this.
>>
>
> OK. Why don't we require the triple to be set and remove the arch
> parameter again?


I am afraid I didn't make it clear in the previous email.  And I am sorry
that I didn't get it when you pointed out this before.

There are two approaches we deal with the triple of the embedded module.
1. The embedded LLVM IR string contains a relatively *complete* module, in
which the target triple is properly set. It means when a user of the
intrinsic generates the embedded LLVM IR string, he need add not only the
function definitions but also the target triple information. When the
intrinsic extract the string into a module, we check whether the triple is
empty. If it is, we return immediately or report errors. In this case, we
needn't the arch parameter.

2. There is no triple information in the embedded LLVM IR string. We get it
from the arch parameter.

With the 1st approach, we avoid some codes about getting the arch string
from arch llvm::Value and generate the triple from the arch string. It
leads less changes to llvm than the 2nd approach. So maybe it is better. We
should add some words to the document that tell the user to set the target
triple info properly in the embedded LLVM IR string.

best regards,
Yabin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120428/a6d0724a/attachment.html>


More information about the llvm-dev mailing list