This is useful for checking inconsistencies between what the remote debug server thinks we are debugging and we think we are debugging. This follows the check for pointer byte size done just above.
Change by Stephane Sezer.
Tested:
Ubuntu 14.04 x86_64, llvm-3.5-built lldb
MacOSX 10.9.4, Xcode-Beta(2014-09-09)-built lldb.
llvm-svn: 217773
This test has a chance to hit some other random allocation
and get neither heap overflow nor SEGV.
Relax test condition to only check that there is no internal CHECK failure.
llvm-svn: 217769
As this is very dependent on the code base it has some ways of configuration.
It's possible to pick between 3 modes of operation:
- Line counting: number of lines including whitespace and comments
- Statement counting: number of statements within compoundStmts.
- Branch counter
In addition a threshold can be picked, warnings are only emitted when it is met.
The thresholds can be configured via a .clang-tidy file.
Differential Revision: http://reviews.llvm.org/D4986
llvm-svn: 217768
when SSE4.1 is available.
This removes a ton of domain crossing from blend code paths that were
ending up in the floating point code path.
This is just the tip of the iceberg though. The real switch is for
integer blend lowering to more actively rely on this instruction being
available so we don't hit shufps at all any longer. =] That will come in
a follow-up patch.
Another place where we need better support is for using PBLENDVB when
doing so avoids the need to have two complementary PSHUFB masks.
llvm-svn: 217767
of the file.
This would run past the end of the buffer. Sadly I don't have a great way to
test it, the only way to trigger the bug is having a removal fix it at the end
of the file, which none of our current warnings can generate.
llvm-svn: 217766
missing specific checks.
While there is a lot of redundancy here where all-but-one mode use the
same code generation, I'd rather have each variant spelled out and
checked so that readers aren't misled by an omission in the test suite.
llvm-svn: 217765
Summary:
These two functions are unavailable on MSVC2012, which breaks building the
ASAN tests with MSVC2012. Since the tests required to run these functions
are disabled on Windows for now, avoid building them to fix the MSVC2012
builds.
Test Plan: This is needed in order to fix building the ASAN tests with MSVC2012.
Reviewers: timurrrr
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5343
llvm-svn: 217763
Summary: This is copied from llvm/utils/unittest/CMakeLists.txt.
Test Plan: This partly enables building ASAN tests with MSVC2012.
Reviewers: timurrrr
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5342
llvm-svn: 217762
instructions from the relevant shuffle patterns.
This is the last tweak I'm aware of to generate essentially perfect
v4f32 and v2f64 shuffles with the new vector shuffle lowering up through
SSE4.1. I'm sure I've missed some and it'd be nice to check since v4f32
is amenable to exhaustive exploration, but this is all of the tricks I'm
aware of.
With AVX there is a new trick to use the VPERMILPS instruction, that's
coming up in a subsequent patch.
llvm-svn: 217761
instructions when it finds an appropriate pattern.
These are lovely instructions, and its a shame to not use them. =] They
are fast, and can hand loads folded into their operands, etc.
I've also plumbed the comment shuffle decoding through the various
layers so that the test cases are printed nicely.
llvm-svn: 217758
AVX is available, and generally tidy up things surrounding UNPCK
formation.
Originally, I was thinking that the only advantage of PSHUFD over UNPCK
instruction variants was its free copy, and otherwise we should use the
shorter encoding UNPCK instructions. This isn't right though, there is
a larger advantage of being able to fold a load into the operand of
a PSHUFD. For UNPCK, the operand *must* be in a register so it can be
the second input.
This removes the UNPCK formation in the target-specific DAG combine for
v4i32 shuffles. It also lifts the v8 and v16 cases out of the
AVX-specific check as they are potentially replacing multiple
instructions with a single instruction and so should always be valuable.
The floating point checks are simplified accordingly.
This also adjusts the formation of PSHUFD instructions to attempt to
match the shuffle mask to one which would fit an UNPCK instruction
variant. This was originally motivated to allow it to match the UNPCK
instructions in the combiner, but clearly won't now.
Eventually, we should add a MachineCombiner pass that can form UNPCK
instructions post-RA when the operand is known to be in a register and
thus there is no loss.
llvm-svn: 217755
'punpckhwd' instructions when suitable rather than falling back to the
generic algorithm.
While we could canonicalize to these patterns late in the process, that
wouldn't help when the freedom to use them is only visible during
initial lowering when undef lanes are well understood. This, it turns
out, is very important for matching the shuffle patterns that are used
to lower sign extension. Fixes a small but relevant regression in
gcc-loops with the new lowering.
When I changed this I noticed that several 'pshufd' lowerings became
unpck variants. This is bad because it removes the ability to freely
copy in the same instruction. I've adjusted the widening test to handle
undef lanes correctly and now those will correctly continue to use
'pshufd' to lower. However, this caused a bunch of churn in the test
cases. No functional change, just churn.
Both of these changes are part of addressing a general weakness in the
new lowering -- it doesn't sufficiently leverage undef lanes. I've at
least a couple of patches that will help there at least in an academic
sense.
llvm-svn: 217752
Use fully qualified name inside a typedef from llvm::iterator_range<...> to
iterator_range. This is reported (rightly I think) by GCC as an
ambiguous name redefinition. Hope this fixes the buildbots.
llvm-svn: 217751
Some ICmpInsts when anded/ored with another ICmpInst trivially reduces
to true or false depending on whether or not all integers or no integers
satisfy the intersected/unioned range.
This sort of trivial looking code can come about when InstCombine
performs a range reduction-type operation on sdiv and the like.
This fixes PR20916.
llvm-svn: 217750
Summary:
replaceAllUsesWith had been modified to allow a DbgNode value to be
replaced by itself. In that case a new node is created by copying the
current DbgNode and the copy is used as replacement value.
When that copying happens, the value stored in this->DbgNode at the end
of RAUW would be a reference to the Node that has just been deleted.
This doesn't produce any bug right now, because the DI node on which we
call RAUW won't be used again.
Reviewers: dblaikie, echristo, aprantl
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5326
llvm-svn: 217749
RAUW was only used on DIType to merge declarations and full definitions
of types. In order to support the same functionality for functions and
global variables, move the function up type DI type hierarchy to the
common parent of DIType, DISubprogram and DIVariable which is
DIDescriptor.
This functionality will be exercized when we add the code to emit
imported declarations for forward declared function/variables.
Reviewers: echristo, dblaikie, aprantl
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5325
llvm-svn: 217748
A DWARFUnitSection is the collection of Units that have been extracted from
the same debug section.
By embeding a reference to their DWARFUnitSection in each unit, the DIEs
will be able to resolve inter-unit references by interrogating their Unit's
DWARFUnitSection.
This is a minimal patch where the DWARFUnitSection is-a SmallVector of Units,
thus exposing exactly the same interface as before. Followup-up patches might
change from inheritance to composition in order to expose only the wanted
DWARFUnitSection abstraction.
Differential Revision: http://reviews.llvm.org/D5310
llvm-svn: 217747
A single function in SourceCoverageDataManager was the only user of
some of the comparisons in CounterMappingRegion, and at this point we
know that only one file is relevant. This lets us use slightly simpler
logic directly in the client.
llvm-svn: 217745
These are super simple. They even take precedence over crazy
instructions like INSERTPS because they have very high throughput on
modern x86 chips.
I still have to teach the integer shuffle variants about this to avoid
so many domain crossings. However, due to the particular instructions
available, that's a touch more complex and so a separate patch.
Also, the backend doesn't seem to realize it can commute blend
instructions by negating the mask. That would help remove a number of
copies here. Suggestions on how to do this welcome, it's an area I'm
less familiar with.
llvm-svn: 217744
support transforming the forms from the new vector shuffle lowering to
use 'movddup' when appropriate.
A bunch of the cases where we actually form 'movddup' don't actually
show up in the test results because something even later than DAG
legalization maps them back to 'unpcklpd'. If this shows back up as
a performance problem, I'll probably chase it down, but it is at least
an encoded size loss. =/
To make this work, also always do this canonicalizing step for floating
point vectors where the baseline shuffle instructions don't provide any
free copies of their inputs. This also causes us to canonicalize
unpck[hl]pd into mov{hl,lh}ps (resp.) which is a nice encoding space
win.
There is one test which is "regressed" by this: extractelement-load.
There, the test case where the optimization it is testing *fails*, the
exact instruction pattern which results is slightly different. This
should probably be fixed by having the appropriate extract formed
earlier in the DAG, but that would defeat the purpose of the test.... If
this test case is critically important for anyone, please let me know
and I'll try to work on it. The prior behavior was actually contrary to
the comment in the test case and seems likely to have been an accident.
llvm-svn: 217738
pointer to a dead function. To make sure it's valid, doFinalization nullptrs
RewindFunction just like the constructor and so it will be found on next run.
llvm-svn: 217737
... Just make sure we check uses first so we see the kill first. It
turns out ignoring defs gives some pretty nasty runtime failures.
I'm certain this is the fix but I'm still reducing a testcase.
llvm-svn: 217735
During the IslAst parallelism check also compute the minimal dependency
distance and store it in the IstAst for node.
Reviewer: sebpop
Differential Revision: http://reviews.llvm.org/D4987
llvm-svn: 217729
Even though we previously correctly detected the multi-dimensional access
pattern for accesses with a certain base address, we only delinearized
non-affine accesses to this address. Affine accesses have not been touched and
remained as single dimensional accesses. The result was an inconsistent
description of accesses to the same array, with some being one dimensional and
some being multi-dimensional.
This patch ensures that all accesses are delinearized with the same
dimensionality as soon as a single one of them has been detected as non-affine.
While writing this patch, it became evident that the options
-polly-allow-nonaffine and -polly-detect-keep-going have not been properly
supported in case delinearization has been turned on. This patch adds relevant
test coverage and addresses these issues as well. We also added some more
documentation to the functions that are modified in this patch.
This fixes llvm.org/PR20123
Differential Revision: http://reviews.llvm.org/D5329
llvm-svn: 217728
At the moment we assume that only elements of identical size are stored/loaded
to a certain base pointer. This patch adds logic to the scop detection to verify
this.
Differential Revision: http://reviews.llvm.org/D5329
llvm-svn: 217727
Matt Arsenault