[cfe-dev] Is it possible to select UnknownArch through command line in clang?

Reid Kleckner rnk at google.com
Wed May 28 11:17:53 PDT 2014


On Tue, May 27, 2014 at 7:56 PM, Zvonimir Rakamaric <zvonimir at cs.utah.edu>wrote:

> Ok, yes, we should probably take a step back...
>
> What SMACK currently does not like is type coercion when for example
> {i32,i32} is packed into i64 before a function call, and so on. And
> the reason is that this often requires byte-level reasoning that is
> not supported in SMACK, and on top of that supporting it would almost
> certainly add a performance overhead.
>

Sometimes this is desirable because it more closely models in LLVM IR what
is actually happening on x86_64.


> So what I learned after poking around clang source is that enabling
> DefaultTargetCodeGenInfo solves this problem since it disables most of
> such coercions. After learning that, I ventured into figuring out how
> to select DefaultTargetCodeGenInfo from command line, and it appears
> that is not possible. Is that right?
>
> Now, I got to UnknownArch by tracking the source code back from where
> DefaultTargetCodeGenInfo gets selected. If I remember correctly, clang
> will select DefaultTargetCodeGenInfo if UnknownArch is selected in the
> Triple. So then I started asking how to select UnknownArch...
>

This all makes sense.  :)


> One final question: why does DefaultTargetCodeGenInfo even exist if it
> cannot be selected?


DefaultTargetCodeGenInfo is essentially an abstract base class for other
ABIs.

I think you should do something like what PNaCl does and add a new virtual
ISA like "smack64" or "le64" that has a known data layout, endianness, etc,
and always uses 'byval' when passing structs by value.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140528/8cc7d48e/attachment.html>


More information about the cfe-dev mailing list