| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 225501
|
|
|
|
| |
llvm-svn: 225500
|
|
|
|
|
|
| |
Share logic for getting the last instruction emitted.
llvm-svn: 225499
|
|
|
|
|
|
| |
Prepare to simplify the `DebugLoc` record.
llvm-svn: 225498
|
|
|
|
|
|
|
| |
This cannot yet be enabled by default, it causes ~50 miscompiles in the test
suite.
llvm-svn: 225497
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The main issue that this patch is trying to address is that the current
implementation of getRerunArgs of InlineTest relies on the attribute
'using_dsym' which could be absent if the test was skipped altogether.
[That is, if both dsym and dwarf tests were skipped.]
While at it, the use of deprecated Python module 'new' is eliminated.
Test Plan: [Linux] dotest.py -p TestExprPathSynthetic
Reviewers: vharron, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6888
llvm-svn: 225496
|
|
|
|
|
|
|
|
|
| |
We were previously emitting counter increments even if we didn't have
an insertion point, which would result in a CallInst with no
parent. This leads to a crash, as in pr22166, if we try to do
GlobalDCE.
llvm-svn: 225495
|
|
|
|
|
|
|
|
|
|
|
| |
We forgot to mark designated initializer expression that contain type
dependent array designators as type dependent. This would lead to
crashes when we try to determine which array element we were trying to
initialize.
This fixes PR22056.
llvm-svn: 225494
|
|
|
|
|
|
|
| |
On modern cores with lfiw[az]x, we can fold a sign or zero extension from i32
to i64 into the load necessary for an i64 -> fp conversion.
llvm-svn: 225493
|
|
|
|
|
|
|
|
|
|
| |
As pointed out by Aditya (and Owen), when we elide an FP extend to form an FMA,
we need to extend the incoming operands so that the resulting node will really
be legal. This is currently enabled only for PowerPC, and it happens to work
there regardless, but this should fix the functionality for everyone else
should anyone else wish to use it.
llvm-svn: 225492
|
|
|
|
|
|
|
|
|
|
| |
complements the new vector shuffle lowering code path. This flag,
naturally, is *off* because we've not tested or evaluated the results of
this at all. However, the flag will make it much easier to evaluate
whether we can be this aggressive and whether there are missing vector
shuffle lowering optimizations.
llvm-svn: 225491
|
|
|
|
|
|
|
|
|
|
| |
we're instantiating, if there's a ParmVarDecl within a FunctionDecl context
that is not a parameter of that function. Add some asserts to catch this kind
of issue more generally, and fix another bug exposed by those asserts where we
were missing a local instantiation scope around substitution of
explicitly-specified template arguments.
llvm-svn: 225490
|
|
|
|
|
|
|
|
|
| |
better than the 'template-parameter-x-y' name that we'd get in AST printing,
and is worse in several ways (it's harder to distinguish it from a
user-supplied name, it's wrong after substituting some number of outer
levels, it wastes time and space constructing an IdentifierInfo, ...).
llvm-svn: 225489
|
|
|
|
|
|
| |
may have different sizes. Fixes PR22017
llvm-svn: 225488
|
|
|
|
|
|
|
|
| |
This was used previously for metadata but is no longer needed there. Not
doing this simplifies ValueHandle and will make it easier to fix things
like AssertingVH's DenseMapInfo.
llvm-svn: 225487
|
|
|
|
|
|
|
|
|
|
|
|
| |
that we can turn them on by default
Change the default of prefer-dynamic-value to eDynamicDontRunTarget (i.e. enable dynamic values, but do not run code to do so)
Of course, disable this for the test suite, since testing no-dynamic-values is actually valuable
Fixes rdar://17363061
llvm-svn: 225486
|
|
|
|
|
|
|
|
|
|
|
|
| |
As pointed out by Aditya (and Owen), there are two things wrong with this code.
First, it adds patterns which elide FP extends when forming FMAs, and that might
not be profitable on all targets (it belongs behind the pre-existing
aggressive-FMA-formation flag). This is fixed by this change.
Second, the resulting nodes might have operands of different types (the
extensions need to be re-added). That will be fixed in the follow-up commit.
llvm-svn: 225485
|
|
|
|
|
|
| |
https://code.google.com/p/address-sanitizer/issues/detail?id=368
llvm-svn: 225484
|
|
|
|
|
|
|
|
| |
Previously, MemDepPrinter handled volatile and unordered accesses without involving MemoryDependencyAnalysis. By making a slight tweak to the documented interface - which is respected by both callers - we can move this responsibility to MDA for the benefit of any future callers. This is basically just cleanup.
In the future, we may decide to extend MDA's non local dependency analysis to return useful results for ordered or volatile loads. I believe (but have not really checked in detail) that local dependency analyis does get useful results for ordered, but not volatile, loads.
llvm-svn: 225483
|
|
|
|
| |
llvm-svn: 225482
|
|
|
|
|
|
|
|
|
|
| |
Previously, MemoryDependenceAnalysis::getNonLocalPointerDependency was taking a list of properties about the instruction being queried. Since I'm about to need one more property to be passed down through the infrastructure - I need to know a query instruction is non-volatile in an inner helper - fix the interface once and for all.
I also added some assertions and behaviour clarifications around volatile and ordered field accesses. At the moment, this is mostly to document expected behaviour. The only non-standard instructions which can currently reach this are atomic, but unordered, loads and stores. Neither ordered or volatile accesses can reach here.
The call in GVN is protected by an isSimple check when it first considers the load. The calls in MemDepPrinter are protected by isUnordered checks. Both utilities also check isVolatile for loads and stores.
llvm-svn: 225481
|
|
|
|
|
|
|
|
| |
This support is still incomplete and consequently hidden behind a switch that
needs to be enabled. One problem is ATM that we incorrectly interpret very large
unsigned values as negative values even if used in an unsigned comparision.
llvm-svn: 225480
|
|
|
|
|
|
| |
Omission pointed out by Sean Silva!
llvm-svn: 225479
|
|
|
|
|
|
| |
seem like OOMs)
llvm-svn: 225478
|
|
|
|
| |
llvm-svn: 225477
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Create new copies of distinct `MDNode`s instead of following the
uniquing `MDNode` logic.
Just like self-references (or other cycles), `MapMetadata()` creates a
new node. In practice most calls use `RF_NoModuleLevelChanges`, in
which case nothing is duplicated anyway.
Part of PR22111.
llvm-svn: 225476
|
|
|
|
|
|
|
|
|
| |
Update testcases for LLVM change in r225474 to make `MDNode`s explicitly
distinct (when they aren't uniqued).
Part of PR22111.
llvm-svn: 225475
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Propagate whether `MDNode`s are 'distinct' through the other types of IR
(assembly and bitcode). This adds the `distinct` keyword to assembly.
Currently, no one actually calls `MDNode::getDistinct()`, so these nodes
only get created for:
- self-references, which are never uniqued, and
- nodes whose operands are replaced that hit a uniquing collision.
The concept of distinct nodes is still not quite first-class, since
distinct-ness doesn't yet survive across `MapMetadata()`.
Part of PR22111.
llvm-svn: 225474
|
|
|
|
| |
llvm-svn: 225473
|
|
|
|
| |
llvm-svn: 225472
|
|
|
|
|
|
|
|
|
|
|
|
| |
MachineLICM uses a callback named hasLowDefLatency to determine if an
instruction def operand has a 'low' latency. If all relevant operands have a
'low' latency, the instruction is considered too cheap to hoist out of loops
even in low-register-pressure situations. On PowerPC cores, both the embedded
cores and the others, there is no reason to believe that this is a good choice:
all instructions have a cost inside a loop, and hoisting them when not limited
by register pressure is a reasonable default.
llvm-svn: 225471
|
|
|
|
|
|
|
|
| |
Add a command-line option to enable hoisting even cheap instructions (in
low-register-pressure situations). This is turned off by default, but has
proved useful for testing purposes.
llvm-svn: 225470
|
|
|
|
|
|
| |
This should fix https://code.google.com/p/address-sanitizer/issues/detail?id=368.
llvm-svn: 225469
|
|
|
|
|
|
|
| |
Drive-by cleanup; I noticed this when reviewing the patch that became
r225466.
llvm-svn: 225468
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The assert was being triggered when the distance between a constant pool entry
and its user exceeded the maximally allowed distance after thumb2 branch
shortening. A padding was inserted after a thumb2 branch instruction was shrunk,
which caused the user to be out of range. This is wrong as the padding should
have been inserted by the layout algorithm so that the distance between two
instructions doesn't grow later during thumb2 instruction optimization.
This commit fixes the code in ARMConstantIslands::createNewWater to call
computeBlockSize and set BasicBlock::Unalign when a branch instruction is
inserted to create new water after a basic block. A non-zero Unalign causes
the worst-case padding to be inserted when adjustBBOffsetsAfter is called to
recompute the basic block offsets.
rdar://problem/19130476
llvm-svn: 225467
|
|
|
|
|
|
| |
Patch by Ramkumar Ramachandra!
llvm-svn: 225466
|
|
|
|
|
|
|
| |
This was only handling the libcall. This is another example
of why only the intrinsic should ever be used when it exists.
llvm-svn: 225465
|
|
|
|
| |
llvm-svn: 225464
|
|
|
|
|
|
|
|
|
| |
right thing to assert()
It also comes with a (rudimentary) test case that gets itself in a failed update scenario, and checks that we don't crash
This is the easiest case I could think of that forces the failed update case Zachary was seeing
llvm-svn: 225463
|
|
|
|
|
|
| |
"jit" doesn't exist anymore.
llvm-svn: 225462
|
|
|
|
|
|
|
|
|
|
| |
AF = dyn_cast<SCEVAddRecExpr>(Pair.second) may be NULL for some SCEVs that we do
not support. When reporting the error we still want to pass a pointer that is
known to always be non-NULL.
I do not yet have a test case for this, unfortunately.
llvm-svn: 225461
|
|
|
|
|
|
| |
strings from the copies that remain.
llvm-svn: 225460
|
|
|
|
|
|
| |
than a pointer to make unifying code a bit easier.
llvm-svn: 225459
|
|
|
|
|
|
| |
only the subtarget.
llvm-svn: 225458
|
|
|
|
| |
llvm-svn: 225457
|
|
|
|
| |
llvm-svn: 225456
|
|
|
|
| |
llvm-svn: 225455
|
|
|
|
| |
llvm-svn: 225454
|
|
|
|
|
|
|
| |
It now checks for the end of the line or the opening '{'.
While at it, remove empty comments.
llvm-svn: 225451
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: The PIC additions didn't update the prologue and epilogue code to save and restore r30 (PIC base register). This does that.
Test Plan: Tests updated.
Reviewers: hfinkel
Reviewed By: hfinkel
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6876
llvm-svn: 225450
|