maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Sema/arm_vfma.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

13 lines
352 B
C
Raw Normal View History

PR27216: Only define __ARM_FEATURE_FMA when the target has VFPv4 Summary: According to the ACLE spec, "__ARM_FEATURE_FMA is defined to 1 if the hardware floating-point architecture supports fused floating-point multiply-accumulate". This changes clang's behaviour from emitting this macro for v7-A and v7-R cores to only emitting it when the target has VFPv4 (and therefore support for the floating point multiply-accumulate instruction). Fixes PR27216 Reviewers: t.p.northover, rengolin Subscribers: aemerson, rengolin, cfe-commits Differential Revision: http://reviews.llvm.org/D18963 llvm-svn: 267869
2016-04-28 19:29:08 +08:00
// RUN: %clang_cc1 -triple thumbv7-none-eabi -target-feature +neon -target-feature +vfp4 -fsyntax-only -verify %s
ARM: allow both vfma and vfms intrinsics on v7. The main purpose here is that vfma/vfms should be symmetric, and they are supported on most v7 cores. The new ArchGuard is suggested by ACLE but prophylactic for us. Almost all CPUs with NEON *will* have vfma, and the few exceptions I know of (e.g. Cortex-A8) are incorrectly modelled by Clang so can't trigger a test. Fortunately, they're getting rarer. But if we ever do support them properly arm_neon.h should now do the right thing. llvm-svn: 259537
2016-02-03 02:02:10 +08:00
#include <arm_neon.h>
// expected-no-diagnostics
void func(float32x2_t v2f32, float32x4_t v4f32) {
vfma_f32(v2f32, v2f32, v2f32);
vfmaq_f32(v4f32, v4f32, v4f32);
vfms_f32(v2f32, v2f32, v2f32);
vfmsq_f32(v4f32, v4f32, v4f32);
}