[llvm-commits] LLVM patch to support ARM fused multiply add/subtract instructions

[James Molloy]

Hi Anton,

Had to look this up to confirm, but in the ARMARM (V7-AR, 1.4.1) it states: "if the implementation includes VFPv4 it must include Advanced SIMDv2."

So my opinion on the predicates in LLVM is that they should reflect how the ARMARM describes the architecture. That is:

  * VFP4 does not imply NEON.
  * NEONv2 does not imply VFP4.
  * VFP4 && NEON implies NEON is V2.

Refactoring the patch to reflect this would make it a lot easier for a user to map their feature selection to the description in the ARMARM, I think.

Also, the patch doesn't hook the VMLAs up to "Requires<[UseFPVMLx]>" - is there any reason for this? I know that flag isn't really used but when we do hook VMLAs up to fast-math or disable-excess-fp-precision, it'd be nice to have all implementations orthogonal.

Cheers,

James

-----Original Message-----
From: Anton Korobeynikov [mailto:anton at korobeynikov.info] 
Sent: 24 January 2012 08:47
To: James Molloy
Cc: Ana Pazos; rajav at codeaurora.org; llvm-commits at cs.uiuc.edu
Subject: Re: [llvm-commits] LLVM patch to support ARM fused multiply add/subtract instructions

Hi James,

> I'm not 100% happy with this patch. The implementation means that -mattr=+neon,+vfp4 does not enable neon-vfp4, which I think is rather confusing.
> I'd much prefer the predicate to be rewritten such that hasNEONVFP4() === hasNEONVFP4 || (hasVFP4 && hasNEON), what do you think?
Is it possible for a core to have vfpv4, but have "previous" neon?
VFPv3-like? Or it's pretty tied situation? So, on VFPv4 core NEON will
also always be VFPv4 ?

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University