[llvm-commits] PATCH: Add support to llvm::Triple for computing 32-bit and 64-bit variant triples.

[Eric Christopher]

On Feb 1, 2012, at 12:59 AM, Chandler Carruth wrote:

> On Wed, Feb 1, 2012 at 12:51 AM, Eric Christopher <echristo at apple.com> wrote:
> 
> On Jan 30, 2012, at 10:25 PM, Chandler Carruth wrote:
> 
> > This patch teaches the Triple class to compute 32-bit variants of 64-bit architectures and 64-bit variants of 32-bit architectures. These can be used when reasoning about what alternate triples may have semi-compatible toolchains such as multiarch and bi-arch toolchains. The goal in placing this logic here is to associate it closely with the triple and architecture definitions themselves so that as those change, this gets updated and maintained.
> >
> > Comments on the somewhat clunky API welcome. The reason I went with returning a full triple rather than operating exclusively on the Arch is to make code using the interface as concise as possible.
> 
> Any reason why the 32-bit version of an already 32-bit arch returns unknown rather than the existing arch itself?
> 
> Because it's not much of a variant?
> 
> I thought of 3 possible behaviors: assert, return self, return unknown
> 
> I'm happy with any of the three. I picked the return unknown as it technically simplifies what i expect to be the common client:
> 
> Triple AltTriple = MyTriple.getArch32BitVariant();
> if (AltTriple.getArch() != Triple::UnknownArch) {
>   // Try alt
> }
> 
> But I could be persuaded to any of the other behaviors. =]

:)

I'd have thought returning identity would be easier to handle in the "gimme the 32-bit variant" "you're on it already, done." "*uses 32-bit variant*" and error/return unknown if one really doesn't exist.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120201/0038357c/attachment.html>