LWN.net Logo

[fedora-arm] totally crap llvm nonsense patch

From:  Jon Masters <jcm-H+wXaHxf7aLQT0dZR+AlfA-AT-public.gmane.org>
To:  arm-TuqUDEhatI4ANWPb/1PvSmm0pvjS0E/A-AT-public.gmane.org
Subject:  [fedora-arm] totally crap llvm nonsense patch
Date:  Wed, 14 Nov 2012 00:54:15 -0500
Message-ID:  <50A33207.9070706@redhat.com>
Archive-link:  Article, Thread

Hey Folks,

This is *not* a patch. It's a collection of random crap I wrote ages and
ages ago. Don't use it. But, I started poking at this ages ago and I am
short of time (I'm rapidly beginning to learn that I don't scale how I
want to, though I can perhaps usefully assist others if I get over my
need for things to be perfect before posting and share stuff more often!
Only took 30 years to learn that life lesson...), so you might use this
to begin tracking down where the Triplet code needs to be modified to
support Fedora. The biggest problem is that the LLVM developers (in
their infinite wisdom[0]) decided that the only way triplets can
possibly be done is the Debian/Ubuntu way (gnueabihf), and so our
treating armv7hl as an architecture variant makes it explode. But not
just in the obvious way, in fun and exciting ways. For those following
along at home, our triplet needs to be:

armv7hl-redhat-linux-gnueabi

And none of the following:

arm-*-linux-gnu
arm-*-linux-gnueabi
arm-*-linux-gnueabihf
armv7hl-*-linux-gnu
armv7hl-*-linux-gnueabihf

etc.

So, if I get time over the holidays, I'm going to fix this properly, and
it'll look nothing like this nonsense crap I just posted.

Jon.

[0] I personally believe LLVM is the latest shiny thing. It's not better
than gcc, it's just the new new new new cloud cloud cloud! equivalent of
compiler technology so everyone is falling over themselves to get on an
LLVM bandwagon in time to fragment the existing support we have, thus
requiring support for two compilers over just one. But that's a
digression. Suffice it to say, I'm not a fanboy.
diff -urNp llvm-3.1.src_orig/include/llvm/ADT/Triple.h llvm-3.1.src_hack/include/llvm/ADT/Triple.h
--- llvm-3.1.src_orig/include/llvm/ADT/Triple.h	2012-04-02 14:31:33.000000000 -0400
+++ llvm-3.1.src_hack/include/llvm/ADT/Triple.h	2012-08-23 12:22:27.392322210 -0400
@@ -43,7 +43,7 @@ public:
   enum ArchType {
     UnknownArch,
 
-    arm,     // ARM; arm, armv.*, xscale
+    arm,     // ARM: arm, armv.*, xscale
     cellspu, // CellSPU: spu, cellspu
     hexagon, // Hexagon: hexagon
     mips,    // MIPS: mips, mipsallegrex
@@ -65,7 +65,7 @@ public:
     ptx32,   // PTX: ptx (32-bit)
     ptx64,   // PTX: ptx (64-bit)
     le32,    // le32: generic little-endian 32-bit CPU (PNaCl / Emscripten)
-    amdil   // amdil: amd IL
+    amdil    // amdil: amd IL
   };
   enum VendorType {
     UnknownVendor,
@@ -74,7 +74,8 @@ public:
     PC,
     SCEI,
     BGP,
-    BGQ
+    BGQ,
+    RedHat
   };
   enum OSType {
     UnknownOS,
diff -urNp llvm-3.1.src_orig/lib/Support/Triple.cpp llvm-3.1.src_hack/lib/Support/Triple.cpp
--- llvm-3.1.src_orig/lib/Support/Triple.cpp	2012-04-02 14:31:33.000000000 -0400
+++ llvm-3.1.src_hack/lib/Support/Triple.cpp	2012-08-23 12:22:27.392322210 -0400
@@ -90,6 +90,7 @@ const char *Triple::getVendorTypeName(Ve
   case SCEI: return "scei";
   case BGP: return "bgp";
   case BGQ: return "bgq";
+  case RedHat: return "redhat";
   }
 
   llvm_unreachable("Invalid VendorType!");
diff -urNp llvm-3.1.src_orig/tools/clang/lib/Driver/ToolChains.cpp
llvm-3.1.src_hack/tools/clang/lib/Driver/ToolChains.cpp
--- llvm-3.1.src_orig/tools/clang/lib/Driver/ToolChains.cpp	2012-05-11 20:16:02.000000000 -0400
+++ llvm-3.1.src_hack/tools/clang/lib/Driver/ToolChains.cpp	2012-08-24 08:34:04.172308597 -0400
@@ -1185,8 +1185,13 @@ Generic_GCC::GCCInstallationDetector::GC
   static const char *const ARMLibDirs[] = { "/lib" };
   static const char *const ARMTriples[] = {
     "arm-linux-gnueabi",
+    "armv5tel-redhat-linux-gnueabi",
     "arm-linux-androideabi"
   };
+  static const char *const ARMHFTriples[] = {
+    "arm-linux-gnueabihf",
+    "armv7hl-redhat-linux-gnueabi"
+  };
 
   static const char *const X86_64LibDirs[] = { "/lib64", "/lib" };
   static const char *const X86_64Triples[] = {
@@ -1233,12 +1238,23 @@ Generic_GCC::GCCInstallationDetector::GC
   };
 
   switch (TargetTriple.getArch()) {
+
   case llvm::Triple::arm:
   case llvm::Triple::thumb:
+  {
+    StringRef TargetTripleStr = TargetTriple.str();
+
     LibDirs.append(ARMLibDirs, ARMLibDirs + llvm::array_lengthof(ARMLibDirs));
-    TripleAliases.append(
-      ARMTriples, ARMTriples + llvm::array_lengthof(ARMTriples));
+    if ((TargetTriple.getEnvironment() == llvm::Triple::GNUEABIHF) ||
+        (TargetTripleStr.startswith("armv7hl"))) {
+      TripleAliases.append(
+        ARMHFTriples, ARMHFTriples + llvm::array_lengthof(ARMHFTriples));
+    } else {
+      TripleAliases.append(
+        ARMTriples, ARMTriples + llvm::array_lengthof(ARMTriples));
+    }
     break;
+  }
   case llvm::Triple::x86_64:
     LibDirs.append(
       X86_64LibDirs, X86_64LibDirs + llvm::array_lengthof(X86_64LibDirs));
@@ -1362,6 +1378,7 @@ void Generic_GCC::GCCInstallationDetecto
 
       Version = CandidateVersion;
       GCCTriple.setTriple(CandidateTriple);
+
       // FIXME: We hack together the directory name here instead of
       // using LI to ensure stable path separators across Windows and
       // Linux.
@@ -1826,6 +1843,8 @@ enum LinuxDistro {
   Fedora14,
   Fedora15,
   Fedora16,
+  Fedora17,
+  Fedora18,
   FedoraRawhide,
   OpenSuse11_3,
   OpenSuse11_4,
@@ -1885,7 +1904,11 @@ static LinuxDistro DetectLinuxDistro(llv
 
   if (!llvm::MemoryBuffer::getFile("/etc/redhat-release", File)) {
     StringRef Data = File.get()->getBuffer();
-    if (Data.startswith("Fedora release 16"))
+    if (Data.startswith("Fedora release 18"))
+      return Fedora18;
+    else if (Data.startswith("Fedora release 17"))
+      return Fedora17;
+    else if (Data.startswith("Fedora release 16"))
       return Fedora16;
     else if (Data.startswith("Fedora release 15"))
       return Fedora15;
@@ -1957,6 +1980,16 @@ static std::string getMultiarchTriple(co
     // common linux triples that don't quite match the Clang triple for both
     // 32-bit and 64-bit targets. Multiarch fixes its install triples to these
     // regardless of what the actual target triple is.
+  case llvm::Triple::arm:
+  case llvm::Triple::thumb:
+    if (TargetTriple.getEnvironment() == llvm::Triple::GNUEABIHF) {
+      if (llvm::sys::fs::exists(SysRoot + "/lib/arm-linux-gnueabihf"))
+        return "arm-linux-gnueabihf";
+    } else {
+      if (llvm::sys::fs::exists(SysRoot + "/lib/arm-linux-gnueabi"))
+        return "arm-linux-gnueabi";
+    }
+    return TargetTriple.str();
   case llvm::Triple::x86:
     if (llvm::sys::fs::exists(SysRoot + "/lib/i386-linux-gnu"))
       return "i386-linux-gnu";
@@ -2197,6 +2230,9 @@ void Linux::AddClangSystemIncludeArgs(co
   const StringRef ARMMultiarchIncludeDirs[] = {
     "/usr/include/arm-linux-gnueabi"
   };
+  const StringRef ARMHFMultiarchIncludeDirs[] = {
+    "/usr/include/arm-linux-gnueabihf"
+  };
   const StringRef MIPSMultiarchIncludeDirs[] = {
     "/usr/include/mips-linux-gnu"
   };
@@ -2215,7 +2251,10 @@ void Linux::AddClangSystemIncludeArgs(co
   } else if (getTriple().getArch() == llvm::Triple::x86) {
     MultiarchIncludeDirs = X86MultiarchIncludeDirs;
   } else if (getTriple().getArch() == llvm::Triple::arm) {
-    MultiarchIncludeDirs = ARMMultiarchIncludeDirs;
+    if (getTriple().getEnvironment() == llvm::Triple::GNUEABIHF)
+      MultiarchIncludeDirs = ARMHFMultiarchIncludeDirs;
+    else
+      MultiarchIncludeDirs = ARMMultiarchIncludeDirs;
   } else if (getTriple().getArch() == llvm::Triple::mips) {
     MultiarchIncludeDirs = MIPSMultiarchIncludeDirs;
   } else if (getTriple().getArch() == llvm::Triple::mipsel) {
diff -urNp llvm-3.1.src_orig/tools/clang/lib/Driver/Tools.cpp
llvm-3.1.src_hack/tools/clang/lib/Driver/Tools.cpp
--- llvm-3.1.src_orig/tools/clang/lib/Driver/Tools.cpp	2012-04-18 17:32:25.000000000 -0400
+++ llvm-3.1.src_hack/tools/clang/lib/Driver/Tools.cpp	2012-08-23 12:22:27.402321428 -0400
@@ -610,18 +610,17 @@ static StringRef getARMFloatABI(const Dr
       break;
     }
 
-    case llvm::Triple::Linux: {
-      if (Triple.getEnvironment() == llvm::Triple::GNUEABI) {
-        FloatABI = "softfp";
-        break;
-      }
-    }
-    // fall through
-
     default:
       switch(Triple.getEnvironment()) {
+      case llvm::Triple::GNUEABIHF:
+        FloatABI = "hard";
+        break;
       case llvm::Triple::GNUEABI:
-        FloatABI = "softfp";
+        // Linux distributions like Fedora set the float ABI in the arch name
+        if (Triple.getArchName().startswith("armv7hl"))
+          FloatABI = "hard";
+        else
+          FloatABI = "softfp";
         break;
       case llvm::Triple::EABI:
         // EABI is always AAPCS, and if it was not marked 'hard', it's softfp
@@ -666,6 +665,7 @@ void Clang::AddARMTargetArgs(const ArgLi
     switch(Triple.getEnvironment()) {
     case llvm::Triple::ANDROIDEABI:
     case llvm::Triple::GNUEABI:
+    case llvm::Triple::GNUEABIHF:
       ABIName = "aapcs-linux";
       break;
     case llvm::Triple::EABI:
_______________________________________________
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

(Log in to post comments)

[fedora-arm] totally crap llvm nonsense patch

Posted Nov 19, 2012 17:06 UTC (Mon) by daglwn (subscriber, #65432) [Link]

Wow. If that's the attitude of the gcc developers they're going to get left behind.

I am a professional compiler developer. After looking at many options, commercial and FOSS, we decided on LLVM. It really wasn't even close. The design is much cleaner, it is much easier to integrate into an existing project and it has a very helpful and friendly community.

LLVM has its faults. Many of them, in fact. But many fewer than other comparable systems.

[fedora-arm] totally crap llvm nonsense patch

Posted Nov 19, 2012 17:30 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

What gave you the impression that Jon Masters has anything to do with GCC developers?

[fedora-arm] totally crap llvm nonsense patch

Posted Nov 19, 2012 19:47 UTC (Mon) by daglwn (subscriber, #65432) [Link]

Whoops, you are right. I guess I jumped to that conclusion because of some previous messages by gcc developers. My apologies.

Compiler wars

Posted Nov 27, 2012 3:36 UTC (Tue) by ncm (subscriber, #165) [Link]

It used to be hard to tell whether someone hated (or loved) LLVM because of something actually in LLVM, or just because it's (nominally) coded in C++. Now that Gcc is officially (if also nominally) coded in C++, we may observe who newly hates both, and draw our conclusions. Note that some already hated both, so we can't tell anything new about them -- although many of us hold opinions already. In principle a similar proviso applies to those who already loved both, or do now, but that has no practical application.

Copyright © 2012, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds