Summary:
When computing branch weights in BPI, we used to disallow branches with
weight 0. This is a minor nuisance, because a branch with weight 0 is
different to "don't have information". In the context of
instrumentation, it may mean "never executed", in the context of
sampling, it means "never or seldom executed".
In allowing 0 weight branches, I ran into issues with the switch
expansion code in selection DAG. It is currently hardwired to not handle
branches with weight 0. To maintain the current behaviour, I changed it
to use 1 when it finds 0, but perhaps the algorithm needs changes to
tolerate branches with weight zero.
Reviewers: hansw
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9533
llvm-svn: 236617
The patch disabled unrolling in loop vectorization pass when VF==1 on x86 architecture,
by setting MaxInterleaveFactor to 1. Unrolling in loop vectorization pass may introduce
the cost of overflow check, memory boundary check and extra prologue/epilogue code when
regular unroller will unroll the loop another time. Disable it when VF==1 remove the
unnecessary cost on x86. The same can be done for other platforms after verifying
interleaving/memory bound checking to be not perf critical on those platforms.
Differential Revision: http://reviews.llvm.org/D9515
llvm-svn: 236613
Summary:
Adds test to check that when getLazyBitcodeModule is called:
1) Functions are not materailzed by default.
2) Only the requested function gets materialized (if no block addresses
are used).
Reviewers: jvoung, rafael
Reviewed By: rafael
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8907
llvm-svn: 236611
With neon enabled, we reach SelectBinaryFPOp and are able to get registers for a <2 x double> add.
However, we shouldn't actually attempt arithmetic on it as ARMIselLowering says "v2f64 is legal so that QR subregs can be extracted as f64 elements, but neither Neon nor VFP support any arithmetic operations on it."
This commit disables SelectBinaryFPOp for any vector types. There's already a FIXME to try handle neon. Doing so would require fixing this conditional which isn't safe for vectors 'VT == MVT::f64 || VT == MVT::i64'
llvm-svn: 236609
The new implementation was ported from the AMD builtin library
and has been tested with piglit, OpenCV, and the ocl conformance tests.
llvm-svn: 236608
Summary:
GetEHFrameAugmentedUnwindPlan duplicated the work of GetEHFrameUnwindPlan in getting the original
plan from DWARF CFI. This changes the function to call GetEHFrameUnwindPlan instead of doing all
the work itself. A copy constructor is added to UnwindPlan to enable plan copying.
Test Plan: No regressions on linux test suite.
Reviewers: jasonmolenda, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9369
llvm-svn: 236607
The initial code drop for VSX swap optimization permitted the
optimization only when all operations in a web of related computation
are lane-insensitive. For some lane-sensitive operations, we can
still permit the optimization provided that we make adjustments to
those operations. This patch adds special handling for vector splats
so that their presence doesn't kill the optimization.
Vector splats are lane-sensitive since they identify by number a
vector element to be used as the source of a splat. When swap
optimizations take place, the desired vector element will move to the
opposite doubleword of the quadword vector. We thus replace the index
I by (I + N/2) % N, where N is the number of elements in the vector.
A new test case is added to test that swap optimization succeeds when
vector splats are present, and that the proper input element is used
as the source of the splat.
An ancillary change removes SH_BUILDVEC as one of the kinds of special
handling that may be required by VSX swap optimization. From
experience with GCC, I had expected to need some modifications for
vector build operations, but I did not find that to be the case.
llvm-svn: 236606
Before:
[aaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaa:
aaaaaaaa aaa:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa];
After:
[aaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaa:aaaaaaaa
aaa:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa];
Note that this might now violate the column limit and we probably need an
alternative way of indenting these then. However, that is still strictly better
than the messy formatting that clang-format did before.
llvm-svn: 236598
Summary:
The lambda was always calling SetState(eStateStopped) with small variations, so I have inlined
the code. Given that we don't have the TSC anymore, I believe we don't need to be so generic.
The only major change here is the way we choose a stop reason thread when we're interrupting a
program on client request. Previously, we were setting a null stop reason for all threads and
then fixing up the reason for one victim thread in the lambda. Now, I make sure the stop reason
is set for the victim thread correctly in the first place.
I also take the opportunity to rename CallAfter* functions into something more appropriate.
Test Plan: All tests continue to pass.
Reviewers: chaoren, vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9321
llvm-svn: 236595
In the process, fix an old todo that I don't really know how to write
tests for. The problem is that Clang's lexer creates very strange token
sequences for these. However, the new approach seems generally better
and easier to read so I am submitting it nonetheless.
llvm-svn: 236589
Summary:
Since all TSC operations are now executed synchronously, TSC has become a little more than a
messenger between different parts of NativeProcessLinux. Therefore, the reason for its existance
has disappeared.
This commit moves the contents of the TSC into the NPL class. This will enable us to remove all
the boilerplate code in NPL (as it stands now, this is most of the class), which I plan to do in
subsequent commits.
Unfortunately, this also means we will lose the unit tests for the TSC. However, since the size
of the TSC has diminished, the unit tests were not testing much at this point anyway, so it's not
a big loss.
No functional change.
Test Plan: All tests continue to pass.
Reviewers: vharron, chaoren
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9296
llvm-svn: 236587
Summary: This patch correctly handles undef case of EXTRACT_VECTOR_ELT node where the element index is constant and not less than vector size.
Test Plan:
CodeGen for X86 test included.
Also one incorrect regression test fixed.
Reviewers: qcolombet, chandlerc, hfinkel
Reviewed By: hfinkel
Subscribers: hfinkel, llvm-commits
Differential Revision: http://reviews.llvm.org/D9250
llvm-svn: 236584
This patch also changes the implementation of the ArrayInfoMap to a MapVector
which will ensure that iterating over the list of ArrayInfo objects gives
predictable results. The single loop that currently enumerates the ArrayInfo
objects only frees the individual objectes, hence a possibly changing
iteration order does not affect the outcome. The added robustness is for
future users of this interface.
llvm-svn: 236583
Summary:
This is a cleanup patch for thread state coordinator. After making processing of all events
synchronous, there is no need to have a a separate class for each event. I have moved back
processing of all events back into the TSC class. No functional change.
Test Plan: All tests continue to pass.
Reviewers: chaoren, vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9254
llvm-svn: 236576
I folded the check for the flag -verify-dom-info into the only caller
where I think it is supposed to be checked: verifyAnalysis. (The idea
of the flag is to enable this expensive verification in
verifyPreservedAnalysis.)
I'm assuming that when manually scheduling the verification pass
with -passes=verify<domtree>, we do want to perform the verification.
llvm-svn: 236575
Splitting:
/**
* multiline block comment
*
*/
Before:
/**
* multiline block
*comment
*
*/
After:
/**
* multiline block
* comment
*
*/
The reason was that the empty line inside the comment (with just the "*") was
confusing the comment breaking logic.
llvm-svn: 236573
Symbol for pc used in ucontext->uc_mcontext was wrong.
Reviewers: dsanders, kcc, samsonov
Subscribers: llvm-commits, mohit.bhakkad, jaydeep
Differential Revision: http://reviews.llvm.org/D9246
llvm-svn: 236572
Andrey Churbanov