Hi all,<div><br></div><div>I revised the llvm.codegen intrinsic according to all your comments.</div><div>Further discussion and review are welcome.</div><div>Main changes are list here.</div><div>1. remove the arg parameter.</div>
<div>2. add mcpu and features parameters.</div><div>3. <meta http-equiv="content-type" content="text/html; charset=utf-8">Document that users of the intinsic should set the target triple in the llvm IR string properly.</div>
<div>4. fix the bug of calling addPassesToEmitFile, using true for the verifier flag.</div><div><br></div><div>Thanks a lot!</div><div><br></div><div>best regards,</div><div>Yabin<br><br><div class="gmail_quote">2012/4/30 Tobias Grosser <span dir="ltr"><<a href="mailto:tobias@grosser.es" target="_blank">tobias@grosser.es</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 04/29/2012 08:28 PM, Evan Cheng wrote:<br>
><br>
> On Apr 29, 2012, at 6:37 AM, Tobias Grosser wrote:<br>
><br>
>><br>
>> OK, I get what you mean. The intrinsic is currently targeted at the<br>
>> OpenCL/CUDA model. It is the most widely used. Stuff like cell sounds<br>
>> interesting, but probably needs further thoughts. Even with OpenCL/CUDA,<br>
>> this intrinsic works currently only for PTX code generation, but I hope<br>
>> we can gain support for other GPU devices later on.<br>
>><br>
>>>     I agree that future work can be useful here. However, before<br>
>>>     spending a large amount of time to engineer a complex solution, I<br>
>>>     propose to start with the proposed light-weight approach. It is<br>
>>>     sufficient for our needs and will allow us to get the experience and<br>
>>>     infrastructure that can help us to choose and implement a more<br>
>>>     complex later on.<br>
>>><br>
>>><br>
>>> I agree that this approach is the best way to get short-term results,<br>
>>> especially for the GSoC project.<br>
>><br>
>> OK, let's go ahead.<br>
>><br>
>> Yabin, can you update the patch with the following changes:<br>
>><br>
>> - Remove the Arch flag<br>
>> - Document that we require a triple<br>
>> - Add two new arguments that take a feature string and a mcpu<br>
>>    flag (can be set to "", which means we use the default)<br>
><br>
> Wait. I don't think there is enough justification for this to move forward. Apart from the technical issues that have already been raised. I can also see this introduces a safety issue since the embedded IR code is not checked / verified at compile time. Unless Chris says otherwise, I don't see this patch being accepted on trunk.<br>

<br>
</div>Hi Even,<br>
<br>
sure, this patch needs further discussion and an OK of some kind of<br>
global maintainer. Neither me or Justin can give permission for a change<br>
at this place. I mainly asked Yabin to provide a version that addresses<br>
concerns raised by Justin, to give further reviewers an up to date<br>
version to look at.<br>
<br>
With your comment, you actually pointed out a bug.<br>
<br>
Instead of:<br>
Target->addPassesToEmitFile(PM, FOS,<br>
                             TargetMachine::CGFT_AssemblyFile,<br>
                             CodeGenOpt::Default)<br>
<br>
We should use:<br>
bool UseVerifier = true;<br>
Target->addPassesToEmitFile(PM, FOS,<br>
                             TargetMachine::CGFT_AssemblyFile,<br>
                             UseVerifier)<br>
<br>
Though, I don't think that is the problem you where talking about. Could<br>
you explain what security issues you exactly see? The embedded LLVM-IR<br>
is checked by the IR verifier the same as the host IR is. For both<br>
LLVM-IR modules the target code is generated and consequently verified<br>
at the same time. The embedded IR is _not_ compiled later than the host<br>
IR. What did I miss?<br>
<br>
Cheers<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
><br>
> Evan<br>
><br>
>><br>
>> Cheers<br>
>> Tobi<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div>