r236060 - Stop emitting the soft-float and soft-float-abi target features

[Nico Weber]

This caused PR23375. It's possible we're holding something wrong (we didn't
change how we hold things recently), but since this was advertised as not
changing behavior I reverted it for now in r236159.

On Tue, Apr 28, 2015 at 4:18 PM, Eric Christopher <echristo at gmail.com>
wrote:

> Author: echristo
> Date: Tue Apr 28 18:18:33 2015
> New Revision: 236060
>
> URL: http://llvm.org/viewvc/llvm-project?rev=236060&view=rev
> Log:
> Stop emitting the soft-float and soft-float-abi target features
> for ARM while the backend will only ignore them. No functional
> change intended.
>
> Modified:
>     cfe/trunk/lib/Driver/Tools.cpp
>
> Modified: cfe/trunk/lib/Driver/Tools.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=236060&r1=236059&r2=236060&view=diff
>
> ==============================================================================
> --- cfe/trunk/lib/Driver/Tools.cpp (original)
> +++ cfe/trunk/lib/Driver/Tools.cpp Tue Apr 28 18:18:33 2015
> @@ -714,29 +714,6 @@ static void getARMTargetFeatures(const D
>                                   const ArgList &Args,
>                                   std::vector<const char *> &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 D
>
>    // 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.
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150429/de7ee698/attachment.html>