| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
This patch updates IntelJITEventListener.cpp to account for revision 206654, which removed some methods from DILineInfo.
llvm-svn: 209989
|
| |
|
|
| |
llvm-svn: 209988
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was previously committed in r209680 and reverted in r209683 after
it caused sanitizer builds to crash.
The issue seems to be that the DebugLoc associated with dbg.value IR
intrinsics isn't necessarily accurate. Instead, we duplicate the
DIVariables and add an InlinedAt field to them to record their
location.
We were using this InlinedAt field to compute the LexicalScope for the
variable, but not using it in the abstract DbgVariable construction and
mapping. This resulted in a formal parameter to the current concrete
function, correctly having no InlinedAt information, but incorrectly
having a DebugLoc that described an inlined location within the
function... thus an abstract DbgVariable was created for the variable,
but its DIE was never constructed (since the LexicalScope had no such
variable). This DbgVariable was silently ignored (by testing for a
non-null DIE on the abstract DbgVariable).
So, fix this by using the right scoping information when constructing
abstract DbgVariables.
In the long run, I suspect we want to undo the work that added this
second kind of location tracking and fix the places where the DebugLoc
propagation on the dbg.value intrinsic fails. This will shrink debug
info (by not duplicating DIVariables), make it more efficient (by not
having to construct new DIVariable metadata nodes to try to map back to
a single variable), and benefit all instructions.
But perhaps there are insurmountable issues with DebugLoc quality that
I'm unaware of... I just don't know how we can't /just keep the DebugLoc
from the dbg.declare to the dbg.values and never get this wrong/.
Some history context:
http://llvm.org/viewvc/llvm-project?view=revision&revision=135629
http://llvm.org/viewvc/llvm-project?view=revision&revision=137253
llvm-svn: 209984
|
| |
|
|
| |
llvm-svn: 209982
|
| |
|
|
| |
llvm-svn: 209981
|
| |
|
|
| |
llvm-svn: 209980
|
| |
|
|
|
|
| |
These patterns are already handled in the instruction definition.
llvm-svn: 209979
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DAG cycle detection is only enabled with ENABLE_EXPENSIVE_CHECKS. However we
can run it just before we would crash in order to provide more informative
diagnostics.
Now in addition to the "Overran sorted position" message we also get the Node
printed if a cycle was detected.
Tested by building several configs: Debug+Assert, Debug+Assert+Check (this is
ENABLE_EXPENSIVE_CHECKS), Release+Assert and Release. Also tried that the
AssignTopologicalOrder assert produces the expected results.
llvm-svn: 209977
|
| |
|
|
|
|
|
|
|
| |
Pass the DAG down to checkForCycles from all callers where we have it. This
allows target-specific nodes to be printed properly.
Also print some missing newlines.
llvm-svn: 209976
|
| |
|
|
|
|
|
| |
Prefer the decl in SelectionDAGNodes.h because it's used there and
SelectionDAG.h includes SelectionDAGNodes.h.
llvm-svn: 209975
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Handle "X + ~X" -> "-1" in the function Value *Reassociate::OptimizeAdd(Instruction *I, SmallVectorImpl<ValueEntry> &Ops);
This patch implements:
TODO: We could handle "X + ~X" -> "-1" if we wanted, since "-X = ~X+1".
Patch by Rahul Jain!
Differential Revision: http://reviews.llvm.org/D3835
llvm-svn: 209973
|
| |
|
|
| |
llvm-svn: 209971
|
| |
|
|
| |
llvm-svn: 209968
|
| |
|
|
|
|
|
|
|
|
| |
Input YAML file might contain multiple object file definitions.
New option `-docnum` allows to specify an ordinal number (starting from 1)
of definition used for an object file generation.
Patch reviewed by Sean Silva.
llvm-svn: 209967
|
| |
|
|
| |
llvm-svn: 209964
|
| |
|
|
| |
llvm-svn: 209961
|
| |
|
|
| |
llvm-svn: 209960
|
| |
|
|
| |
llvm-svn: 209957
|
| |
|
|
|
|
|
| |
There is no std::error_code::success, so this removes much of the noise
in transitioning to std::error_code.
llvm-svn: 209952
|
| |
|
|
| |
llvm-svn: 209951
|
| |
|
|
|
|
|
| |
Following the lead set by r209324, I'm making these tests match the whole
instruction, so we can be sure we're lowering them correctly.
llvm-svn: 209947
|
| |
|
|
|
|
| |
blacklisted functions
llvm-svn: 209946
|
| |
|
|
| |
llvm-svn: 209945
|
| |
|
|
|
|
| |
blacklisted functions
llvm-svn: 209939
|
| |
|
|
| |
llvm-svn: 209938
|
| |
|
|
| |
llvm-svn: 209937
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
legalization when promoting nodes with illegal vector type.
This patch teaches the backend how to simplify/canonicalize dag node
sequences normally introduced by the backend when promoting certain dag nodes
with illegal vector type.
This patch adds two new combine rules:
1) fold (shuffle (bitcast (BINOP A, B)), Undef, <Mask>) ->
(shuffle (BINOP (bitcast A), (bitcast B)), Undef, <Mask>)
2) fold (BINOP (shuffle (A, Undef, <Mask>)), (shuffle (B, Undef, <Mask>))) ->
(shuffle (BINOP A, B), Undef, <Mask>).
Both rules are only triggered on the type-legalized DAG.
In particular, rule 1. is a target specific combine rule that attempts
to sink a bitconvert into the operands of a binary operation.
Rule 2. is a target independet rule that attempts to move a shuffle
immediately after a binary operation.
llvm-svn: 209930
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If both vector args to vselect are concat_vectors and the condition is
constant and picks half a vector from each argument, convert the vselect
into a concat_vectors.
Added a test.
The ConvertSelectToConcatVector is assuming it doesn't get vselects with
arguments of, for example, <undef, undef, true, true>. Those get taken
care of in the checks above its call.
Reviewers: nadav, delena, grosbach, hfinkel
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D3916
llvm-svn: 209929
|
| |
|
|
|
|
| |
block and remove the unreachable code.
llvm-svn: 209927
|
| |
|
|
|
|
| |
rest of the targets with a similar function name.
llvm-svn: 209926
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Separate the check for blend shuffle_vector masks into isBlendMask.
This function will also be used to check if a vector shuffle is legal. No
change in functionality was intended, but we ended up improving codegen on
two tests, which were being (more) optimized only if the resulting shuffle
was legal.
Reviewers: nadav, delena, andreadb
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D3964
llvm-svn: 209923
|
| |
|
|
| |
llvm-svn: 209921
|
| |
|
|
| |
llvm-svn: 209920
|
| |
|
|
| |
llvm-svn: 209918
|
| |
|
|
| |
llvm-svn: 209916
|
| |
|
|
|
|
|
|
|
|
| |
speculation.
This helps more branches into selects. On R600,
vectors are cheap and anything that helps
remove branches is very good.
llvm-svn: 209914
|
| |
|
|
|
|
|
|
|
| |
For MIPS, we have to encode the personality routine with
an indirect pointer to absptr; otherwise, some link warning
warning will be raised, and the program might crash in some
early MIPS Android device.
llvm-svn: 209907
|
| |
|
|
|
|
|
| |
This test specifies an ARM triple, so it needs ARM as a registered
target.
llvm-svn: 209905
|
| |
|
|
|
|
| |
Patch by suyog sarda.
llvm-svn: 209903
|
| |
|
|
|
|
| |
Patch by Andrey Kuharev.
llvm-svn: 209902
|
| |
|
|
|
|
|
|
|
| |
Unordered is strictly weaker than monotonic, so if the latter doesn't have any
barriers then the former certainly shouldn't.
rdar://problem/16548260
llvm-svn: 209901
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Darwin prologues save their GPRs in two stages: a narrow push of r0-r7 & lr,
followed by a wide push of the remaining registers if there are any. AAPCS uses
a single push.w instruction.
It turns out that, on average, enough registers get pushed that code is smaller
in the AAPCS prologue, which is a nice property for M-class programmers. They
also have other options available for back-traces, so can hopefully deal with
the fact that FP & LR aren't adjacent in memory.
rdar://problem/15909583
llvm-svn: 209895
|
| |
|
|
|
|
|
|
|
| |
This makes LLVM create N_INDR aliases (to be resolved by the linker) when
appropriate.
rdar://problem/15125513
llvm-svn: 209894
|
| |
|
|
| |
llvm-svn: 209885
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The C and C++ semantics for compare_exchange require it to return a bool
indicating success. This gets mapped to LLVM IR which follows each cmpxchg with
an icmp of the value loaded against the desired value.
When lowered to ldxr/stxr loops, this extra comparison is redundant: its
results are implicit in the control-flow of the function.
This commit makes two changes: it replaces that icmp with appropriate PHI
nodes, and then makes sure earlyCSE is called after expansion to actually make
use of the opportunities revealed.
I've also added -{arm,aarch64}-enable-atomic-tidy options, so that
existing fragile tests aren't perturbed too much by the change. Many
of them either rely on undef/unreachable too pervasively to be
restored to something well-defined (particularly while making sure
they test the same obscure assert from many years ago), or depend on a
particular CFG shape, which is disrupted by SimplifyCFG.
rdar://problem/16227836
llvm-svn: 209883
|
| |
|
|
| |
llvm-svn: 209880
|
| |
|
|
|
|
| |
test cases.
llvm-svn: 209877
|
| |
|
|
|
|
|
|
|
|
| |
Vectorizer.
This patch adds support to vectorize intrinsics such as powi, cttz and ctlz in Vectorizer. These intrinsics are different from other
intrinsics as second argument to these function must be same in order to vectorize them and it should be represented as a scalar.
Review: http://reviews.llvm.org/D3851#inline-32769 and http://reviews.llvm.org/D3937#inline-32857
llvm-svn: 209873
|
| |
|
|
|
|
|
| |
I'm using this pretty frequently in a patch I'm working on and it seems
generally useful.
llvm-svn: 209872
|
| |
|
|
| |
llvm-svn: 209871
|