From 535c8ba7a164bc5a2021846787fb01e4abfb3561 Mon Sep 17 00:00:00 2001 From: Eric Christopher Date: Tue, 28 Apr 2015 23:18:33 +0000 Subject: [PATCH] Stop emitting the soft-float and soft-float-abi target features for ARM while the backend will only ignore them. No functional change intended. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236060 91177308-0d34-0410-b5e6-96231b3b80d8 --- lib/Driver/Tools.cpp | 24 +----------------------- 1 file changed, 1 insertion(+), 23 deletions(-) diff --git a/lib/Driver/Tools.cpp b/lib/Driver/Tools.cpp index 10837996a3..6fb9b54a01 100644 --- a/lib/Driver/Tools.cpp +++ b/lib/Driver/Tools.cpp @@ -714,29 +714,6 @@ static void getARMTargetFeatures(const Driver &D, const llvm::Triple &Triple, const ArgList &Args, std::vector &Features, bool ForAS) { - StringRef FloatABI = tools::arm::getARMFloatABI(D, Args, Triple); - if (!ForAS) { - // FIXME: Note, this is a hack, the LLVM backend doesn't actually use these - // yet (it uses the -mfloat-abi and -msoft-float options), and it is - // stripped out by the ARM target. We should probably pass this a new - // -target-option, which is handled by the -cc1/-cc1as invocation. - // - // FIXME2: For consistency, it would be ideal if we set up the target - // machine state the same when using the frontend or the assembler. We don't - // currently do that for the assembler, we pass the options directly to the - // backend and never even instantiate the frontend TargetInfo. If we did, - // and used its handleTargetFeatures hook, then we could ensure the - // assembler and the frontend behave the same. - - // Use software floating point operations? - if (FloatABI == "soft") - Features.push_back("+soft-float"); - - // Use software floating point argument passing? - if (FloatABI != "hard") - Features.push_back("+soft-float-abi"); - } - // Honor -mfpu=. if (const Arg *A = Args.getLastArg(options::OPT_mfpu_EQ)) getARMFPUFeatures(D, A, Args, Features); @@ -745,6 +722,7 @@ static void getARMTargetFeatures(const Driver &D, const llvm::Triple &Triple, // Setting -msoft-float effectively disables NEON because of the GCC // implementation, although the same isn't true of VFP or VFP3. + StringRef FloatABI = tools::arm::getARMFloatABI(D, Args, Triple); if (FloatABI == "soft") { Features.push_back("-neon"); // Also need to explicitly disable features which imply NEON. -- 2.40.0