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

[Eric Christopher]

Thanks Nico, I didn't see the bug report. It'd be nice to get a test
checked in that covers whatever use case is going on.

-eric

On Wed, Apr 29, 2015 at 2:21 PM Nico Weber <thakis at chromium.org> wrote:

> 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/a9498a7f/attachment.html>