| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
it vectorizable.
llvm-svn: 293162
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with it.
This code was dereferencing the PoisoningVH which isn't allowed once it
is poisoned. But the code itself really doesn't need to access the
pointer, it is just doing the safe stuff of clearing out data structures
keyed on the pointer value.
Change the code to use iterators to erase directly from a DenseMap. This
is also substantially more efficient as it avoids lots of hashing and
lookups to do the erasure. DenseMap supports iterating behind the
iteration which is fairly easy to implement.
Sadly, I don't have a test case here. I'm not even close and I don't
know that I ever will be. The issue is that several of the tricky
aspects of fixing this only show up when you cause the stack's
SmallVector to be in *EXACTLY* the right location. I only ever got
a reproduction for those with Clang, and only with *exactly* the right
command line flags. Any adjustment, even to seemingly unrelated flags,
would make partial and half-way solutions magically start to "work". In
good news, all of this was caught with the LLVM test suite. Also, there
is no *specific* code here that is untested, just that the old pattern
of code won't immediately fail on any test case I've managed to
contrive.
llvm-svn: 293160
|
| |
|
|
|
|
| |
"this", aka class members, is not referred in the body.
llvm-svn: 293159
|
| |
|
|
|
|
| |
-Winconsistent-missing-override.
llvm-svn: 293158
|
| |
|
|
|
|
| |
DAG combine phase where I had originally meant to put it.
llvm-svn: 293157
|
| |
|
|
|
|
| |
operations, use the correct type for the immediate operand.
llvm-svn: 293156
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactoring to remove duplications of this method.
New method getOperandsScalarizationOverhead() that looks at the present unique
operands and add extract costs for them. Old behaviour was to just add extract
costs for one operand of the type always, which still happens in
getArithmeticInstrCost() if no operands are provided by the caller.
This is a good start of improving on this, but there are more places
that can be improved by using getOperandsScalarizationOverhead().
Review: Hal Finkel
https://reviews.llvm.org/D29017
llvm-svn: 293155
|
| |
|
|
| |
llvm-svn: 293153
|
| |
|
|
|
|
| |
undef subvectors.
llvm-svn: 293152
|
| |
|
|
|
|
|
|
| |
This intrinsic uses bit 0 and bit 4 of an immediate argument to determine which bits of its inputs to read. This patch uses this information to simplify the demanded elements of the input vectors.
Differential Revision: https://reviews.llvm.org/D28979
llvm-svn: 293151
|
| |
|
|
| |
llvm-svn: 293150
|
| |
|
|
| |
llvm-svn: 293148
|
| |
|
|
|
|
| |
It will be used from clang.
llvm-svn: 293145
|
| |
|
|
| |
llvm-svn: 293137
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
factory functions for the two modes the loop unroller is actually used
in in-tree: simplified full-unrolling and the entire thing including
partial unrolling.
I've also wired these up to nice names so you can express both of these
being in a pipeline easily. This is a precursor to actually enabling
these parts of the O2 pipeline.
Differential Revision: https://reviews.llvm.org/D28897
llvm-svn: 293136
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
directly walks the current loop structure verifying that a matching
structure can be found in a freshly computed version.
Also pull things out of containers when necessary once an issue is found
and print them directly.
This makes it substantially easier to debug verification failures as
the process stops at the exact point in the loop nest where they diverge
and has in easily accessed local variables (or printed to stderr
already) the loops and other information needed to analyze the failure.
Differential Revision: https://reviews.llvm.org/D29142
llvm-svn: 293133
|
| |
|
|
|
|
|
|
|
|
| |
obj-path.
Now we never append a number to the file name for task ID 0.
Differential Revision: https://reviews.llvm.org/D29160
llvm-svn: 293132
|
| |
|
|
| |
llvm-svn: 293131
|
| |
|
|
| |
llvm-svn: 293129
|
| |
|
|
| |
llvm-svn: 293128
|
| |
|
|
| |
llvm-svn: 293127
|
| |
|
|
| |
llvm-svn: 293126
|
| |
|
|
|
|
| |
sure it is not asan/msan-instrumented
llvm-svn: 293125
|
| |
|
|
|
|
|
|
|
|
|
| |
Even when we don't create a remainder loop (that is, when we unroll by 2), we
may duplicate nested loops into the remainder. This is complicated by the fact
the remainder may itself be either inserted into an outer loop, or at the top
level. In the latter case, we may need to create new top-level loops.
Differential Revision: https://reviews.llvm.org/D29156
llvm-svn: 293124
|
| |
|
|
|
|
|
|
| |
Otherwise we ask for a domtree node that's not there, and we crash.
Differential Revision: https://reviews.llvm.org/D29145
llvm-svn: 293122
|
| |
|
|
|
|
|
| |
This is the opt/llc counterpart of -fsave-optimization-record to output
optimization remarks in a YAML file.
llvm-svn: 293121
|
| |
|
|
|
|
| |
Thanks to Davide Italiano for finding the problem and providing a test case.
llvm-svn: 293119
|
| |
|
|
|
|
| |
dumping the PCs
llvm-svn: 293117
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fix comments in response to jlebar's comments in D27872.
Reviewers: jlebar
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29109
llvm-svn: 293116
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously we assumed that the result of sqrt(x) always had 0 as its
sign bit. But sqrt(-0) == -0.
Reviewers: hfinkel, efriedma, sanjoy
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28928
llvm-svn: 293115
|
| |
|
|
|
|
| |
the clang-x86-windows-msvc2015 bot as the name is "llvm-nm.EXE" in that case.
llvm-svn: 293114
|
| |
|
|
|
|
| |
Analogous to the code in opt, this enables hotness in opt-remarks.
llvm-svn: 293113
|
| |
|
|
| |
llvm-svn: 293112
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows MIR passes to emit optimization remarks with the same level
of functionality that is available to IR passes.
It also hooks up the greedy register allocator to report spills. This
allows for interesting use cases like increasing interleaving on a loop
until spilling of registers is observed.
I still need to experiment whether reporting every spill scales but this
demonstrates for now that the functionality works from llc
using -pass-remarks*=<pass>.
Differential Revision: https://reviews.llvm.org/D29004
llvm-svn: 293110
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Code region is the only part of this class that is IR-specific. Code
region is moved down in the inheritance tree to a new derived class,
called DiagnosticInfoIROptimization.
All the existing remarks are derived from this new class now.
This allows the new MIR pass-remark classes to be derived from
DiagnosticInfoOptimizationBase.
Also because we keep the name DiagnosticInfoOptimizationBase, the clang
parts don't need any adjustment.
Differential Revision: https://reviews.llvm.org/D29003
llvm-svn: 293109
|
| |
|
|
| |
llvm-svn: 293105
|
| |
|
|
|
|
|
|
| |
This eliminates one overload on the term Raw.
Differential Revision: https://reviews.llvm.org/D29098
llvm-svn: 293104
|
| |
|
|
|
|
|
|
|
| |
Document the current practice regarding dropping metadata on modules,
functions and global variables.
Differential Revision: https://reviews.llvm.org/D29110
llvm-svn: 293101
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Mach-O files don’t have size information about the symbols in the object file
format unlike ELF.
Also add the part of the fix to llvm-nm that was missed with r290001 so
-arch armv7m works.
rdar://25681018
llvm-svn: 293099
|
| |
|
|
|
|
|
|
|
|
| |
supports it"
This reverts commit r292680. It is causing significantly worse
performance and test timeouts in our internal builds. I have already
routed reproduction instructions your way.
llvm-svn: 293092
|
| |
|
|
| |
llvm-svn: 293091
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is not a list of pairs, it is a hash table data structure. We now
correctly parse this out and dump it from llvm-pdbdump.
We still need to understand the conditions that lead to a type
getting an entry in the hash adjuster table. That will be done
in a followup investigation / patch.
Differential Revision: https://reviews.llvm.org/D29090
llvm-svn: 293090
|
| |
|
|
|
|
|
|
| |
Later code expects the vector loads produced to be directly
concatenable, which means we shouldn't pad anything except the last load
produced with UNDEF.
llvm-svn: 293088
|
| |
|
|
|
|
| |
Thanks to Quentin for suggesting the refactoring.
llvm-svn: 293087
|
| |
|
|
|
|
|
| |
I think it's a hold-over from some previous iteration, but it's never
set to true in LLVM as it exists now.
llvm-svn: 293086
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
updater easier
Summary:
This is the first in a series of patches to add a simple, generalized updater to MemorySSA.
For MemorySSA, every def is may-def, instead of the normal must-def.
(the best way to think of memoryssa is "everything is really one variable, with different versions of that variable at different points in the program).
This means when updating, we end up having to do a bunch of work to touch defs below and above us.
In order to support this quickly, i have ilist'd all the defs for each block. ilist supports tags, so this is quite easy. the only slightly messy part is that you can't have two iplists for the same type that differ only whether they have the ownership part enabled or not, because the traits are for the value type.
The verifiers have been updated to test that the def order is correct.
Reviewers: george.burgess.iv
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29046
llvm-svn: 293085
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D29115
llvm-svn: 293083
|
| |
|
|
|
|
|
| |
According to the documentation this is supposed to be -1
if indirect calls are not supported.
llvm-svn: 293081
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch prepares more for tail call support in XRay. Until the logging part supports tail calls, this is just staging, so it seems LLVM part is mostly ready with this patch.
Related: https://reviews.llvm.org/D28948 (compiler-rt)
Reviewers: dberris, rengolin
Reviewed By: dberris
Subscribers: llvm-commits, iid_iunknown, aemerson
Differential Revision: https://reviews.llvm.org/D28947
llvm-svn: 293080
|
| |
|
|
| |
llvm-svn: 293077
|