[llvm-commits] [llvm] r123990 - in /llvm/trunk: include/llvm/ADT/Triple.h lib/Support/Triple.cpp unittests/ADT/TripleTest.cpp

[Renato Golin]

On 01/24/11 10:12, Duncan Sands wrote:
> I don't see the point of having "none" be turned into "NoVendor" rather than
> "UnknownVendor" if you aren't go to do anything with that information anyway.
> However if you have a good reason to want "none" to be parsed then I will
> drop my objections to "none" :)

I guess that falls together with the LLVM/Clang triple implementation.

Clang should interpret UnknownVendor to "none" and not LLVM changed to
have a dubious and duplicated "none".


> In short, whether "none" is parsed at all, or only parsed as a
> valid "O/S", or parsed as a valid vendor and a valid O/S etc depends on what
> triples occur in the real world and what you plan to do with the information.

I agree. My mistake was to try and not break anything that was already
working.

Some ARM triples I found in the wild...

  -- From CodeSourcery:

* arm-none-eabi
   none I "guess" it's for vendor, and no OS

* arm-none-linux-gnueabi
   again, it's vendor

* arm-none-symbianelf
   again, vendor is none, but OS and Env (ELF) are joined up
   also, ELF and EABI are not auto-exclusive

* arm-uclinuxeabi
   OS/Env joined up again, but nothing for vendor... weird

  -- From GCC docs:

* arm-*-freebsd
* arm-*-netbsdelf
* arm-*-*linux
* arm-*-rtems
   Nothing new here...

  -- From a GCC bug (16350):

* armv5b-softfloat-linux
   'b' means big-endian, and softfloat is the Env.

As you can see, ARM triples are a mess. Most of them will fail to parse
in the naive triple parsing LLVM has today. I'm not saying we should add
hack-logic to it, though.

What we could do is to have a ClangTriple to pre-parse the hacks and
transform into a triple conforming to the LLVM standards
(pre-normalise), and then pass to the Triple to parse it and normalise.

This way, that normalised (correct) triple will be printed in the IR and
LLC will understand it perfectly.

Example:

Clang cmd-line:
  - arm-uclinuxeabi
ClangTriple:
  - arm-uclinux-eabi
Triple:
  - arm--uclinux-eabi
Clang writes on IR:
  - arm-none-uclinux-eabi
LLC:
  - arm--uclinux-eabi (vendor is UnknownVendor)

Does it make sense?

cheers,
--renato

PS: We're only left with the extra options that the IR cannot represent
today (sub-architecture, build attributes, etc), breaking the two-step
compilation, but that's a complete different problem whatsoever.

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.