| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 220412
|
| |
|
|
|
|
|
|
|
|
| |
This would cause the flag to appear in the output of "llvm-config --cppflags",
which should contain only preprocessor flags. The -gsplit-dwarf flag in
particular can cause problems with certain downstream users such as cgo.
Differential Revision: http://reviews.llvm.org/D5895
llvm-svn: 220410
|
| |
|
|
| |
llvm-svn: 220405
|
| |
|
|
|
|
|
|
| |
Use consistent naming for basic block instances.
No functional changes.
llvm-svn: 220404
|
| |
|
|
| |
llvm-svn: 220402
|
| |
|
|
|
|
|
|
| |
Jenkins likes to use directories with names involving the '@'
character, which breaks the sed expression in this test. Switch to use
'|' on the assumption that it's less likely to show up in a path.
llvm-svn: 220401
|
| |
|
|
| |
llvm-svn: 220399
|
| |
|
|
| |
llvm-svn: 220397
|
| |
|
|
| |
llvm-svn: 220396
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
A previous patch enabled SELECT_VSRC and SELECT_CC_VSRC for VSX to
handle <2 x double> cases. This patch adds SELECT_VSFRC and
SELECT_CC_VSFRC to allow use of all 64 vector-scalar registers for the
f64 type when VSX is enabled. The changes are analogous to those in
the previous patch. I've added a new variant to vsx.ll to test the
code generation.
(I also cleaned up a little formatting in PPCInstrVSX.td from the
previous patch.)
llvm-svn: 220395
|
| |
|
|
|
|
| |
changes.
llvm-svn: 220394
|
| |
|
|
|
|
|
| |
Marking all instructions as CodeGenOnly since encoding bits are not set yet.
http://reviews.llvm.org/D5829?vs=on&id=15023&whitespace=ignore-all#toc
llvm-svn: 220393
|
| |
|
|
|
|
|
|
|
|
| |
When we hoist two loads above an if, we can preserve the nonnull metadata. We could also do the same for sinking them, but we appear to not handle metadata at all in that case.
Thanks to Hal for the review.
Differential Revision: http://reviews.llvm.org/D5910
llvm-svn: 220392
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fast-math (bug 17850)
When a call to a double-precision libm function has fast-math semantics
(via function attribute for now because there is no IR-level FMF on calls),
we can avoid fpext/fptrunc operations and use the float version of the call
if the input and output are both float.
We already do this optimization using a command-line option; this patch just
adds the ability for fast-math to use the existing functionality.
I moved the cl::opt from InstructionCombining into SimplifyLibCalls because
it's only ever used internally to that class.
Modified the existing test cases to use the unsafe-fp-math attribute rather
than repeating all tests.
This patch should solve: http://llvm.org/bugs/show_bug.cgi?id=17850
Differential Revision: http://reviews.llvm.org/D5893
llvm-svn: 220390
|
| |
|
|
| |
llvm-svn: 220389
|
| |
|
|
|
|
|
|
| |
When the profile for a function cannot be applied, we use to emit an
error. This seems extreme. The compiler can continue, it's just that the
optimization opportunities won't include profile information.
llvm-svn: 220386
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The tests test/CodeGen/Generic/select-cc.ll and
test/CodeGen/PowerPC/select-cc.ll both fail with VSX enabled. The
problem is that the lowering logic for the SELECT and SELECT_CC
operations doesn't currently support the VSX registers. This patch
fixes that.
In lib/Target/PowerPC/PPCInstrInfo.td, we have pseudos to handle this
for other register classes. Similar pseudos are added in
PPCInstrVSX.td (they must be there, because the "vsrc" register class
definition appears there) for the VSRC register class. The
SELECT_VSRC pseudo is then used in pattern matching for SELECT_CC.
The rest of the patch just adds logic for SELECT_VSRC wherever similar
logic appears for SELECT_VRRC.
There are no new test cases because the existing tests above test
this, along with a variant in test/CodeGen/PowerPC/vsx.ll.
After discussion with Hal, a future patch will add similar _VSFRC
variants to override f64 type handling (currently using F8RC).
llvm-svn: 220385
|
| |
|
|
|
|
| |
I think it might make sense to make COFF::MaxNumberOfSections16 be a uint32_t, however, that may have wider-reaching implications in other projects, which is why I did not change that declaration.
llvm-svn: 220384
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When using a profile, we used to require the use -gmlt so that we could
get access to the line locations. This is used to match line numbers in
the input profile to the line numbers in the function's IR.
But this is actually not necessary. The driver can provide source
location tracking without the emission of debug information. In these
cases, the annotation 'llvm.dbg.cu' is missing from the IR, but the
actual line location annotations are still present.
This patch adds a new way of looking for the start of the current
function. Instead of looking through the compile units in llvm.dbg.cu,
we can walk up the scope for the first instruction in the function with
a debug loc. If that describes the function, we use it. Otherwise, we
keep looking until we find one.
If no such instruction is found, we then give up and produce an error.
Reviewers: echristo, dblaikie
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5887
llvm-svn: 220382
|
| |
|
|
|
|
| |
And add a long awaited testcase.
llvm-svn: 220381
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ConstantFolding crashes when trying to InstSimplify the following load:
@a = private unnamed_addr constant %mst {
i8* inttoptr (i64 -1 to i8*),
i8* inttoptr (i64 -1 to i8*)
}, align 8
%x = load <2 x i8*>* bitcast (%mst* @a to <2 x i8*>*), align 8
This patch fix this by adding support to this type of folding:
%x = load <2 x i8*>* bitcast (%mst* @a to <2 x i8*>*), align 8
==> gets folded to:
%x = <2 x i8*> <i8* inttoptr (i64 -1 to i8*), i8* inttoptr (i64 -1 to i8*)>
llvm-svn: 220380
|
| |
|
|
|
|
| |
variants in thumb mode
llvm-svn: 220379
|
| |
|
|
| |
llvm-svn: 220377
|
| |
|
|
|
|
| |
It's not handling phis.
llvm-svn: 220371
|
| |
|
|
|
|
|
| |
This fails the verifier with:
"Expected a VCSrc_32 register, but got a VReg_1 register"
llvm-svn: 220368
|
| |
|
|
| |
llvm-svn: 220364
|
| |
|
|
|
|
| |
Thanks to Filipe Cabecinhas for the report.
llvm-svn: 220361
|
| |
|
|
|
|
|
|
| |
gcc's (4.7, I think) -Wcomment warning is not "as smart" as clang's and
warns even if the line right after the backslash-newline sequence only has
a line comment that starts at the beginning of the line.
llvm-svn: 220360
|
| |
|
|
| |
llvm-svn: 220357
|
| |
|
|
| |
llvm-svn: 220355
|
| |
|
|
| |
llvm-svn: 220354
|
| |
|
|
| |
llvm-svn: 220353
|
| |
|
|
| |
llvm-svn: 220352
|
| |
|
|
|
|
|
|
| |
ParamTLS (shadow for function arguments) is of limited size. This change
makes all arguments that do not fit unpoisoned, and avoids writing
past the end of a TLS buffer.
llvm-svn: 220351
|
| |
|
|
|
|
|
|
| |
require" (r220277)
This seems to have caused PR21330.
llvm-svn: 220349
|
| |
|
|
|
|
|
|
|
|
| |
On AArch64, GOT references are page relative (ADRP + LDR), so they can't be
applied until we know exactly where, within a page, the GOT entry will be in
the target address space.
Fixes <rdar://problem/18693976>.
llvm-svn: 220347
|
| |
|
|
| |
llvm-svn: 220346
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Patches 202051 and 208013 added calls to LTO's PassManager which unconditionally add LoopVectorizePass and SLPVectorizerPass instead of following the logic in PassManagerBuilder::populateModulePassManager and honoring the -vectorize-loops -run-slp-after-loop-vectorization flags.
Reviewers: nadav, aschwaighofer, yijiang
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5884
llvm-svn: 220345
|
| |
|
|
| |
llvm-svn: 220344
|
| |
|
|
| |
llvm-svn: 220342
|
| |
|
|
|
|
|
|
|
|
|
|
| |
These are named following the IEEE-754 names for these
functions, rather than the libm fmin / fmax to avoid
possible ambiguities. Some languages may implement something
resembling fmin / fmax which return NaN if either operand is
to propagate errors. These implement the IEEE-754 semantics
of returning the other operand if either is a NaN representing
missing data.
llvm-svn: 220341
|
| |
|
|
|
|
|
|
|
| |
Enumerate `MDNode`'s operands *before* the node itself, so that the
reader requires less RAUW. Although this will cause different code
paths to be hit in the reader, this should effectively be no
functionality change.
llvm-svn: 220340
|
| |
|
|
| |
llvm-svn: 220338
|
| |
|
|
|
|
|
| |
No one cares how many uses each metadata value has, so don't bother
counting.
llvm-svn: 220337
|
| |
|
|
|
|
|
| |
This matches the behavior of GNU ar and also makes it easier to implemnt
support for the addlib command.
llvm-svn: 220336
|
| |
|
|
| |
llvm-svn: 220335
|
| |
|
|
|
|
|
|
|
| |
This is a micro optimization, but also makes the code a bit more flexible.
The MRIMembers variable is a short term hack. It is going away in the next
commit.
llvm-svn: 220334
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This requires incorporating __GNUC_PATCHLEVEL__ into our prerequisite
check, and renaming our __GNUC_PREREQ to LLVM_GNUC_PREREQ, since it is
now functionally different.
Patch by Chilledheart!
Differential Revision: http://reviews.llvm.org/D5879
llvm-svn: 220332
|
| |
|
|
|
|
|
| |
The overridden one wasn't inserting a space,
so you would end up with .globalfoo
llvm-svn: 220329
|
| |
|
|
| |
llvm-svn: 220327
|