[PATCH] D52705: First-pass at ARM hard/soft-float multilib driver (NOT WORKING YET)

2018-10-01 Thread Peter Smith via Phabricator via cfe-commits
peter.smith added a comment.

I think that you may be better off posting a RFC to llvm-dev to get discussion 
on the best approach here. It would also be good to step back a bit and 
consider the requirements, as it stands it looks like this might be a solution 
for just one particular multilib layout and we might be able to get some input 
on some other use cases that others may have. I personally would like to enable 
clang to be able to query a gcc installation to find out (and potentially 
cache) its multlib directories as I've been told for the Arm embedded toolchain 
that the directory structure is not fixed and may change at any point in the 
future.

Another unrelated thing that may be worth doing is to check for other places 
where the target might affect the code-generation independently of -mfloat-abi, 
I'm thinking in particular of builtin functions as this has changed a bit over 
the past few years.




Comment at: lib/Driver/ToolChains/Gnu.cpp:1441
 
+static bool findArmEABIMultilibs(const Driver ,
+ const llvm::Triple ,

When I saw EABIMultilibs I first thought of multilib support for arm-none-eabi 
, I think that this may be worth renaming to something like ArmLinuxGNUEABI as 
this could be specific to Linux Distributions. 



Comment at: lib/Driver/ToolChains/Gnu.cpp:1451
+  bool DefaultHardFloat = TargetTriple.isHardFloatEABI();
+  llvm::Triple AltTriple(DefaultHardFloat ?
+ TargetTriple.getSoftFloatArchVariant() :

AltTriple doesn't seem to be used anywhere in the rest of the function?



Comment at: lib/Driver/ToolChains/Gnu.cpp:1454
+ TargetTriple.getHardFloatArchVariant());
+  // We assume the Debian libdir/includedir arrangement for armel/armhf,
+  // since Debian and its descendents are apparently the only common Linux

Another place where this is used, and clang can't yet handle, is the GCC 
Embedded toolchain arm-none-eabi which includes both hard and soft float abi 
libraries. These have a different structure to the one presented here though.   



Comment at: lib/Driver/ToolChains/Gnu.cpp:1458
+  // SuSE and RedHat seem to stick with hard-float only and no libdir suffix.
+  // TODO: this (and a lot of other code here) could be generalized via the
+  // output of "gcc  --print-multi-os-dir".

I definitely agree here. It seems to me to be quite fragile to hard-code in 
directory structures of gcc toolchains or linux distributions that can, and do, 
vary over time.


Repository:
  rC Clang

https://reviews.llvm.org/D52705



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D52705: First-pass at ARM hard/soft-float multilib driver (NOT WORKING YET)

2018-10-01 Thread Kristina Brooks via Phabricator via cfe-commits
kristina added subscribers: rsmith, kristina.
kristina added reviewers: t.p.northover, rsmith.
kristina added a comment.

Accepted blocking differential https://reviews.llvm.org/D52149, updated 
reviewers to include ARM code owner and @rsmith.


Repository:
  rC Clang

https://reviews.llvm.org/D52705



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D52705: First-pass at ARM hard/soft-float multilib driver (NOT WORKING YET)

2018-09-30 Thread Frank Schaefer via Phabricator via cfe-commits
kelledin created this revision.
Herald added a reviewer: javed.absar.
Herald added subscribers: cfe-commits, chrib, kristof.beyls.

  This is my first crack at implementing working ARM EABI multilib support
  (where multilib support is between hard/soft float ONLY, not between 32-bit
  and 64-bit).  This is currently NOT suitable for merging; I'm only posting
  it for guidance as to what exactly I'm missing.  Specifically, for the
  default-hardfloat target (arm-linux-gnueabihf), clang selects the correct
  GCC suffix (/sf vs /hf) but consistently selects /usr/lib/arm-linux-gnueabihf
  as the library directory, even if soft-float flags are passed.  This leaves
  binutils trying to mix hard-float/soft-float objects, which of course fails
  miserably.  AIUI the multilib driver *should* trigger the selection of
  /usr/lib/arm-linux-gnueabi instead.
  
  I can produce verbose output from clang's behavior upon request.  Be aware
  that this changeset depends on https://reviews.llvm.org/D52149 for 
compiler-rt.


Repository:
  rC Clang

https://reviews.llvm.org/D52705

Files:
  lib/Driver/ToolChains/Arch/ARM.cpp
  lib/Driver/ToolChains/Gnu.cpp
  lib/Driver/ToolChains/Linux.cpp

Index: lib/Driver/ToolChains/Linux.cpp
===
--- lib/Driver/ToolChains/Linux.cpp
+++ lib/Driver/ToolChains/Linux.cpp
@@ -533,8 +533,9 @@
   case llvm::Triple::thumb:
   case llvm::Triple::armeb:
   case llvm::Triple::thumbeb: {
+// NOTE: If no float-ABI selector flags are in use, getARMFloatABI()
+// will fall back on determining ABI by Triple.getEnvironment().
 const bool HF =
-Triple.getEnvironment() == llvm::Triple::GNUEABIHF ||
 tools::arm::getARMFloatABI(*this, Args) == tools::arm::FloatABI::Hard;
 
 LibDir = "lib";
Index: lib/Driver/ToolChains/Gnu.cpp
===
--- lib/Driver/ToolChains/Gnu.cpp
+++ lib/Driver/ToolChains/Gnu.cpp
@@ -808,9 +808,22 @@
   if (!A)
 return false;
 
+  // ARM GNUEABI allows a "softfp" ABI (compatible with soft-float calling
+  // conventions, but can still generate FPU instructions inside functions).
   return A->getOption().matches(options::OPT_msoft_float) ||
  (A->getOption().matches(options::OPT_mfloat_abi_EQ) &&
-  A->getValue() == StringRef("soft"));
+  (A->getValue() == StringRef("soft") || A->getValue() == StringRef("softfp")));
+}
+
+static bool isHardFloatABI(const ArgList ) {
+  Arg *A = Args.getLastArg(options::OPT_msoft_float, options::OPT_mhard_float,
+   options::OPT_mfloat_abi_EQ);
+  if (!A)
+return false;
+
+  return A->getOption().matches(options::OPT_mhard_float) ||
+ (A->getOption().matches(options::OPT_mfloat_abi_EQ) &&
+  A->getValue() == StringRef("hard"));
 }
 
 /// \p Flag must be a flag accepted by the driver with its leading '-' removed,
@@ -1425,6 +1438,75 @@
 Result.Multilibs = RISCVMultilibs;
 }
 
+static bool findArmEABIMultilibs(const Driver ,
+ const llvm::Triple ,
+ StringRef Path, const ArgList ,
+ DetectedMultilibs ) {
+  // Find multilibs with subdirectories like hf (for hard-float) or sf (for
+  // soft-float).  gcc also allows for "-mfloat-abi=softfp": ABI-equivalent
+  // to soft-float, but can still generate FPU instuctions inside functions.
+  // softfp usually has the same multilib subdirectory as soft-float.
+  Multilib Default;
+  bool DefaultHardFloat = TargetTriple.isHardFloatEABI();
+  llvm::Triple AltTriple(DefaultHardFloat ?
+ TargetTriple.getSoftFloatArchVariant() :
+ TargetTriple.getHardFloatArchVariant());
+  // We assume the Debian libdir/includedir arrangement for armel/armhf,
+  // since Debian and its descendents are apparently the only common Linux
+  // distros that have anything resembling multilib support for this scenario.
+  // SuSE and RedHat seem to stick with hard-float only and no libdir suffix.
+  // TODO: this (and a lot of other code here) could be generalized via the
+  // output of "gcc  --print-multi-os-dir".
+  Multilib ArmHFMultilib = makeMultilib("/hf")
+   .osSuffix("/" + TargetTriple.getHardFloatArchVariant().str())
+   .includeSuffix("/" + TargetTriple.getHardFloatArchVariant().str())
+   .flag("+mhard-float")
+   .flag("+mfloat-abi=hard")
+   .flag("-msoft-float")
+   .flag("-mfloat-abi=soft")
+   .flag("-mfloat-abi=softfp");
+  Multilib ArmSFMultilib = makeMultilib("/sf")
+   .osSuffix("/" + TargetTriple.getSoftFloatArchVariant().str())
+   .includeSuffix("/" +