[llvm-commits] [llvm] r154480 - in /llvm/trunk: lib/Target/ARM/ARM.td lib/Target/ARM/ARMAsmPrinter.cpp lib/Target/ARM/ARMInstrInfo.td lib/Target/ARM/ARMInstrNEON.td lib/Target/ARM/ARMInstrVFP.td lib/Target/ARM/ARMSubtarget.cpp lib/Target/ARM/ARMS

[Evan Cheng]

On Apr 11, 2012, at 11:13 AM, Ana Pazos <apazos at codeaurora.org> wrote:

> Hi Evan,
> 
> There was a long discussion on this mailing list about Neon2 when I
> submitted the patch. You can find them all by searching the archive. See
> some of the emails attached.

I've looked through these emails. It's basically impossible to have VFPv4 without NEON2, I don't see the need to add NEON2 feature in the ARM target. Did I miss something? I want to avoid the proliferation of feature bits since it's limited to 64 per target.

> 
> Btw, you can add Neon2 support to clang  instead of reusing neon-vfp4 flag
> which the reviewers did not like.

Is anyone going to use this? We don't want to add new options unless there is a demand.

Evan

> 
> Thanks,
> Ana.
> 
> -----Original Message-----
> From: llvm-commits-bounces at cs.uiuc.edu
> [mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng
> Sent: Wednesday, April 11, 2012 10:21 AM
> To: Anton Korobeynikov
> Cc: llvm-commits at cs.uiuc.edu
> Subject: Re: [llvm-commits] [llvm] r154480 - in /llvm/trunk:
> lib/Target/ARM/ARM.td lib/Target/ARM/ARMAsmPrinter.cpp
> lib/Target/ARM/ARMInstrInfo.td lib/Target/ARM/ARMInstrNEON.td
> lib/Target/ARM/ARMInstrVFP.td lib/Target/ARM/ARMSubtarget.cpp
> lib/Target/ARM/ARMS
> 
> 
> On Apr 11, 2012, at 4:40 AM, Anton Korobeynikov wrote:
> 
>> Hello Evan,
>> 
>>> Clean up ARM fused multiply + add/sub support some more: rename some 
>>> isel predicates.
>>> Also remove NEON2 since it's not really useful and it is confusing. 
>>> If NEON + VFP4 implies NEON2 but NEON2 doesn't imply NEON + VFP4, 
>>> what does it really mean?
>> There was the discussion about this in ML, consider checking it.
> 
> I only saw this:
> 
>> Here is an updated patch for the ARM fused multiply add/sub feature 
>> with the relevant suggestions incorporated.
>> 
>> In this update:
>> - I assumed neon2 does not imply vfpv4, but neon and vfpv4 imply neon2.
> 
> 
> Previously hasNEON2 is both a subtarget feature as well as a isel predicate:
> 'return HasNEON2 || (HasNEON && HasVFPv4);'.
> 
> This is wrong because it would break the assembler and disassembler when you
> pass -mattr=+vfp4 (because HasNEON2 would still be false). Furthermore,
> since (HasNEON && HasVFPv4) implies HasNEON2, it means NEON2 is equal or is
> a subset of the features implied by NEON && HasVFPv4. Since currently there
> are no instructions that are predicated on HasVFPv4 should not be available
> for a target with only NEON2, there is really no point in having this
> subtarget feature.
> 
> Also note:
> 
>> - Regarding Neon2 flag, Code Sourcery GCC seems to support only these
> flags:
>> -mfpu=vfpv4 		
>> -mfpu=vfpv4-d16
>> -mfpu=neon-vfpv4
>> -mfpu=vfpv3-d16-fp16
>> -mfpu=vfpv3-fp16
> 
> There isn't a -mfpu=neon2 flag.
> 
> Evan
> 
> 
>> 
>> --
>> With best regards, Anton Korobeynikov
>> Faculty of Mathematics and Mechanics, Saint Petersburg State 
>> University
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> <Mail Attachment.eml><Mail Attachment.eml><Mail Attachment.eml><Mail Attachment.eml><Mail Attachment.eml><Mail Attachment.eml>