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

[Chandler Carruth]

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. =]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120201/b296811b/attachment.html>