[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 1:01 AM, Eric Christopher <echristo at apple.com> wrote:

>
> 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.
>

Dunno, but doesn't matter to me either way. Since you seem to prefer this
behavior, I've switched. New patch attached.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120205/386a805e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: triple-predicates3.patch
Type: application/octet-stream
Size: 6095 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120205/386a805e/attachment.obj>