<div dir="ltr">Your change seem reasonable to me but I have no say. I suggest you send this to cfe-commits for official review process.<div><br></div><div>Nikola</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">

On Tue, Jun 3, 2014 at 8:12 AM, Zvonimir Rakamaric <span dir="ltr"><<a href="mailto:zvonimir@cs.utah.edu" target="_blank">zvonimir@cs.utah.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hi guys,<br>
<br>
So I created two tiny patches for LLVM and clang that allow target<br>
triples of the form x86_64-unknown-smack to be used, which in turn<br>
disables various type coercions.<br>
<br>
I tested the patches on both LLVM and clang regressions suites, and<br>
they seem to be working fine.<br>
<br>
Please let me know how to proceed with this.<br>
<br>
Thanks!<br>
<div class=""><br>
Best,<br>
-- Zvonimir<br>
<br>
<br>
--<br>
<a href="http://zvonimir.info" target="_blank">http://zvonimir.info</a><br>
<a href="http://soarlab.org/" target="_blank">http://soarlab.org/</a><br>
<br>
<br>
</div>On Wed, May 28, 2014 at 12:28 PM, Zvonimir Rakamaric<br>
<div class="HOEnZb"><div class="h5"><<a href="mailto:zvonimir@cs.utah.edu">zvonimir@cs.utah.edu</a>> wrote:<br>
> On Wed, May 28, 2014 at 12:17 PM, Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br>
>> On Tue, May 27, 2014 at 7:56 PM, Zvonimir Rakamaric <<a href="mailto:zvonimir@cs.utah.edu">zvonimir@cs.utah.edu</a>><br>
>> wrote:<br>
>>><br>
>>> One final question: why does DefaultTargetCodeGenInfo even exist if it<br>
>>> cannot be selected?<br>
>><br>
>> DefaultTargetCodeGenInfo is essentially an abstract base class for other<br>
>> ABIs.<br>
>><br>
>> I think you should do something like what PNaCl does and add a new virtual<br>
>> ISA like "smack64" or "le64" that has a known data layout, endianness, etc,<br>
>> and always uses 'byval' when passing structs by value.<br>
><br>
> This is a great suggestion, thanks!<br>
> Is there any chance that something like smack64 would be integrated<br>
> into the main trunk of clang?<br>
><br>
> Since the main reason why I started this discussion was to hopefully<br>
> come up with a solution that would ultimately not require a patch to<br>
> clang to be applied whenever somebody would like to use it with SMACK.<br>
><br>
> Thanks!<br>
> -- Zvonimir<br>
</div></div></blockquote></div><br></div>