maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
280,954 Commits 23 Branches 0 Tags 2.2 GiB
Commit Graph

6 Commits

Author SHA1 Message Date
Matthias Braun 6b898beb8e X86: Do not use llc -march in tests. 
`llc -march` is problematic because it only switches the target
architecture, but leaves the operating system unchanged. This
occasionally leads to indeterministic tests because the OS from
LLVM_DEFAULT_TARGET_TRIPLE is used.

However we can simply always use `llc -mtriple` instead. This changes
all the tests to do this to avoid people using -march when they copy and
paste parts of tests.

See also the discussion in https://reviews.llvm.org/D35287

llvm-svn: 309774
 2017-08-02 00:28:10 +00:00
Stephen Lin 764d8d3d6f Start using CHECK-LABEL in some tests. 
llvm-svn: 186163
 2013-07-12 14:54:12 +00:00
Stephen Lin 4ee5e873d5 Appease buildbots after r185956: just set -mcpu explicitly, as it should have been from the beginning. 
llvm-svn: 185962
 2013-07-09 19:27:10 +00:00
Stephen Lin 228765f61f Appease Atom buildbot after r185956 (explicitly turn on AVX) 
llvm-svn: 185961
 2013-07-09 18:55:52 +00:00
Stephen Lin 73fa842e2e Attempt to appease buildbot after r185956 by explicitly turning setting -fma,-fma4 attrs (I'm assuming they're set because the bot is running on machine that has one or the other.) 
llvm-svn: 185958
 2013-07-09 18:41:43 +00:00
Stephen Lin 73de7bf5de AArch64/PowerPC/SystemZ/X86: This patch fixes the interface, usage, and all 
in-tree implementations of TargetLoweringBase::isFMAFasterThanMulAndAdd in
order to resolve the following issues with fmuladd (i.e. optional FMA)
intrinsics:

1. On X86(-64) targets, ISD::FMA nodes are formed when lowering fmuladd
intrinsics even if the subtarget does not support FMA instructions, leading
to laughably bad code generation in some situations.

2. On AArch64 targets, ISD::FMA nodes are formed for operations on fp128,
resulting in a call to a software fp128 FMA implementation.

3. On PowerPC targets, FMAs are not generated from fmuladd intrinsics on types
like v2f32, v8f32, v4f64, etc., even though they promote, split, scalarize,
etc. to types that support hardware FMAs.

The function has also been slightly renamed for consistency and to force a
merge/build conflict for any out-of-tree target implementing it. To resolve,
see comments and fixed in-tree examples.

llvm-svn: 185956
 2013-07-09 18:16:56 +00:00