[llvm-commits] PATCH: Add 64-bit architecture predicate to llvm::Triple

James Molloy james.molloy at arm.com
Tue Jan 31 00:30:44 PST 2012


Hi Chandler,

 

That's fine, it was a pedantic nitpick anyway J

 

Cheers,

 

James

 

From: Chris Lattner [mailto:clattner at apple.com] 
Sent: 31 January 2012 04:56
To: Chandler Carruth
Cc: James Molloy; llvm-commits at cs.uiuc.edu; Anton Korobeynikov
Subject: Re: [llvm-commits] PATCH: Add 64-bit architecture predicate to
llvm::Triple

 

 

On Jan 30, 2012, at 8:51 PM, Chandler Carruth wrote:





On Mon, Jan 30, 2012 at 10:08 AM, James Molloy <james.molloy at arm.com> wrote:

Hi Chandler,

 

One point:

 

+  /// Note that this tests for 16-bit pointer width, and nothing else.

 

I'm not sure this comment is accurate. For example, real mode x86 would be
16-bit but has 24-bit pointers (seg:offset).

 

As far as I can tell, there is no support for x86-16 or real mode or any of
the other segmented addressing modes on x86. If such modes are added, I
would be quite happy for them to return false on all three of these queries.
;] I still think "pointer size" is the most descriptive term, but I'm open
to more suggestions.

 

FWIW, the reason I don't particularly like "native width of the register
file" is that i find it much less clear and unambiguous given the diversity
of register widths on even modern architectures. However, addresses
generally have a fixed size on modern architectures, and so that seems a
good classification scheme.

 

Just my contribution to the bikeshed: I don't think that it makes sense for
llvm::Triple to know the "native width of the register file", since that is
such an amorphous statement.  The best that llvm::Triple can know is
sizeof(void*) in the default address space.

 

-Chris

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120131/27cbb7cb/attachment.html>


More information about the llvm-commits mailing list