| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
NDEBUG defined
llvm-svn: 295596
|
| |
|
|
| |
llvm-svn: 295595
|
| |
|
|
| |
llvm-svn: 295594
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We have support for bisection, and bugpoint can reduce testcases
often to a single pass. But that doesn't help reduce it to a single
transform by a single pass. Which debug counting lets us do.
Debug counting lets you instrument a pass so that it only executes a
certain thing (rwhatever you want) after skipping it a certain time of
times, and then only does a certain number of executions before saying
"skip" again.
To make it concrete, for predicateinfo, if i instrument use renaming,
i can make it so it skips renaming the first N uses, renames the next
N, and then skips the rest.
This lets you narrow down a miscompilation to, often, a single
transformation, and then also debug it (by using the same command line
parameters).
Reviewers: chandlerc, davide, mehdi_amini
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29998
llvm-svn: 295593
|
| |
|
|
| |
llvm-svn: 295592
|
| |
|
|
|
|
| |
would run into infinite loop anyways with -Asserts.
llvm-svn: 295591
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Behavior races on ErrorCount. If the enqueued paths are evaluated
eagerly (in enqueuePath) then the behavior is as the test expects. But
they may not be evaluated until the future is waited on, in run() -
which is after the early return/exit on ErrorCount. (this causes the
test to fail (because in the "/ERRORCOUNT:XYZ" test, no other errors
are printed), at least for me, on linux)
This reverts commit r295507.
llvm-svn: 295590
|
| |
|
|
|
|
| |
need them and if we do we should just use a bitcast to a 64-bit element type.
llvm-svn: 295589
|
| |
|
|
| |
llvm-svn: 295588
|
| |
|
|
| |
llvm-svn: 295587
|
| |
|
|
|
|
| |
gcc only allows you to mix enums / ints if they have the same signedness.
llvm-svn: 295586
|
| |
|
|
| |
llvm-svn: 295585
|
| |
|
|
| |
llvm-svn: 295584
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: This begins using the predicateinfo pass in NewGVN.
Reviewers: davide
Subscribers: llvm-commits, Prazek
Differential Revision: https://reviews.llvm.org/D29682
llvm-svn: 295583
|
| |
|
|
|
|
| |
shouldSwapOperands to be correct.
llvm-svn: 295582
|
| |
|
|
|
|
| |
helpers, and fixing support for the renaming the comparison.
llvm-svn: 295581
|
| |
|
|
| |
llvm-svn: 295580
|
| |
|
|
|
|
|
|
| |
parameters instead of doing 128-bit and 256-bit simultaneously.
This requires some instructions to be renamed to move the Y earlier in the instruction name. The new names are more consistent with other instructions.
llvm-svn: 295579
|
| |
|
|
|
|
| |
This was found by another commit I'm working on.
llvm-svn: 295578
|
| |
|
|
|
|
| |
gcc only allows you to mix enums / ints if they have the same signedness.
llvm-svn: 295577
|
| |
|
|
|
|
| |
gcc only allows you to mix enums / ints if they have the same signedness.
llvm-svn: 295576
|
| |
|
|
|
|
| |
Added assertion to check input type of X86ISD::VZEXT during target known bits calculation.
llvm-svn: 295575
|
| |
|
|
|
|
|
|
|
| |
Changing to 'or' (rather than 'xor' when no wrapping flags are set)
allows icmp simplifies to happen as expected.
Differential Revision: https://reviews.llvm.org/D29729
llvm-svn: 295574
|
| |
|
|
|
|
|
|
|
| |
The change to InstCombine in:
https://reviews.llvm.org/D29729
...exposes this missing fold in InstSimplify, so adding this
first to avoid a regression.
llvm-svn: 295573
|
| |
|
|
| |
llvm-svn: 295572
|
| |
|
|
|
|
| |
Clang has now been fixed to not use these intrinsics.
llvm-svn: 295571
|
| |
|
|
| |
llvm-svn: 295570
|
| |
|
|
| |
llvm-svn: 295569
|
| |
|
|
|
|
|
| |
This is the same transform that is current used for:
select Bool, 0, -1
llvm-svn: 295568
|
| |
|
|
|
|
|
|
|
|
|
| |
Instead of counting the number of read-only accesses, we now count the number of
distinct read-only array references when checking if a run-time alias check
may be too complex. The run-time alias check is quadratic in the number of
base pointers, not the number of accesses.
Before this change we accidentally skipped SPEC's lbm test case.
llvm-svn: 295567
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
2 small fixes extracted from
https://reviews.llvm.org/D29064
Reviewers: kuhar, davide, dberlin, george.burgess.iv
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30109
llvm-svn: 295566
|
| |
|
|
|
|
| |
This reverts r295564. I missed that clang was still using the intrinsics despite our half implemented autoupgrade support.
llvm-svn: 295565
|
| |
|
|
|
|
| |
It seems we were already upgrading 128-bit VPCMOV, but the intrinsic was still defined and being used in isel patterns. While I was here I also simplified the tablegen multiclasses.
llvm-svn: 295564
|
| |
|
|
| |
llvm-svn: 295563
|
| |
|
|
| |
llvm-svn: 295562
|
| |
|
|
|
|
|
|
|
| |
This reverts SVN r295329. Although `__libcpp_thread_sleep_for` should
be alertable, the implementation causes a large regression in the test
suite. Add a FIXME item there for now to get the test suite in a better
state before attempting to fix that behaviour.
llvm-svn: 295561
|
| |
|
|
|
|
|
| |
When running under clang-cl mode, we do not define `__GNUC__`, resulting
in the test failing.
llvm-svn: 295560
|
| |
|
|
|
|
|
|
| |
When building with MSVCRT, we need to manually provide the type
promoting overloads to allow the correct type deduced invocation for
signbit(Int) and fpclassify(int).
llvm-svn: 295559
|
| |
|
|
|
|
|
| |
On certain targets, enumerations may be smaller than an `unsigned long`.
Use an explicitly sized enumeration.
llvm-svn: 295558
|
| |
|
|
|
|
| |
This was accepting GFX9 instructions on VI.
llvm-svn: 295557
|
| |
|
|
| |
llvm-svn: 295556
|
| |
|
|
| |
llvm-svn: 295555
|
| |
|
|
| |
llvm-svn: 295554
|
| |
|
|
| |
llvm-svn: 295553
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several visitors check if operands to the instruction are constants,
either as it is or after looking up SimplifiedValues, check if the
result is a constant and update the SimplifiedValues map. This
refactoring splits it into a common function that does the checking of
whether the operands are constants and updating of the SimplifiedValues
table, and an instruction specific part that is implemented by each
instruction visitor as a lambda and passed to the common function.
Differential revision: https://reviews.llvm.org/D30104
llvm-svn: 295552
|
| |
|
|
|
|
| |
This simplifies the code slightly.
llvm-svn: 295551
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change gets rid of the need for zero padding, makes the reduction
computation code more similar to the normal dependence computation, and also
better documents what we do at the moment.
Making the dependence computation for reductions a little bit easier to
understand will hopefully help us to further reduce code duplication.
This reduces the time spent only in the reduction dependence pass from 260ms to
150ms for test/DependenceInfo/reduction_sequence.ll. This is a reduction of over
40% in dependence computation time.
This change was inspired by discussions with Michael Kruse, Utpal Bora,
Siddharth Bhat, and Johannes Doerfert. It can hopefully lay the base for further
cleanups of the reduction code.
llvm-svn: 295550
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test case is a mini performance test case that shows the time needed for a
couple of simple reductions. It takes today about 325ms on my machine to run
this test case through 'opt' with scop construction and reduction detection. It
can be used as mini-proxy for further tuning of the reduction code.
Generally we do not commit performance test cases, but as this is very
small and also very fast it seems OK to keep it in the lit test suite.
This test case will also help to verify that future changes to the reduction
code will not affect the ordering of the reduction sets and will consequently
not cause spurious performance changes that only result from reordering of
dependences in the reduction set.
llvm-svn: 295549
|
| |
|
|
| |
llvm-svn: 295548
|
| |
|
|
|
|
|
|
| |
We're ok shrinking splats, but not shuffles in general.
See https://reviews.llvm.org/D30123 for discussion.
llvm-svn: 295547
|