The code have been developed by Daniel Berlin over the years, and
the new implementation goal is that of addressing shortcomings of
the current GVN infrastructure, i.e. long compile time for large
testcases, lack of phi predication, no load/store value numbering
etc...
The current code just implements the "core" GVN algorithm, although
other pieces (load coercion, phi handling, predicate system) are
already implemented in a branch out of tree. Once the core is stable,
we'll start adding pieces on top of the base framework.
The test currently living in test/Transform/NewGVN are a copy
of the ones in GVN, with proper `XFAIL` (missing features in NewGVN).
A flag will be added in a future commit to enable NewGVN, so that
interested parties can exercise this code easily.
Differential Revision: https://reviews.llvm.org/D26224
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290346 91177308-0d34-0410-b5e6-96231b3b80d8
WebAssembly's load/store offsets are unsigned and don't wrap, so it's not
valid to fold in a negative offset.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290342 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Real instruction should copy constraints from real instruction. This allows auto-generated disassembler to correctly process tied operands.
Reviewers: nhaustov, vpykhtin, tstellarAMD
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, tony-tye
Differential Revision: https://reviews.llvm.org/D27847
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290336 91177308-0d34-0410-b5e6-96231b3b80d8
I was staring at these and didn't realize these were module-layer
proxies as opposed to some other layer. Justin and I have a plan to
rename things to make the names themselves much easier to reason about,
but I at least want the CHECK lines to be precise for now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290328 91177308-0d34-0410-b5e6-96231b3b80d8
declarations.
We're using a custom class here instead of the helper template, these
bits just didn't get deleted when the other bits did get deleted. This
was found by a really nice MSVC warning about explicitly instantiating
a template where some member functions aren't defined and thus can't be
instantiatied.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290327 91177308-0d34-0410-b5e6-96231b3b80d8
from the old pass manager in the new one.
I'm not trying to support (initially) the numerous options that are
currently available to customize the pass pipeline. If we end up really
wanting them, we can add them later, but I suspect many are no longer
interesting. The simplicity of omitting them will help a lot as we sort
out what the pipeline should look like in the new PM.
I've also documented to the best of my ability *why* each pass or group
of passes is used so that reading the pipeline is more helpful. In many
cases I think we have some questionable choices of ordering and I've
left FIXME comments in place so we know what to come back and revisit
going forward. But for now, I've left it as similar to the current
pipeline as I could.
Lastly, I've had to comment out several places where passes are not
ported to the new pass manager or where the loop pass infrastructure is
not yet ready. I did at least fix a few bugs in the loop pass
infrastructure uncovered by running the full pipeline, but I didn't want
to go too far in this patch -- I'll come back and re-enable these as the
infrastructure comes online. But I'd like to keep the comments in place
because I don't want to lose track of which passes need to be enabled
and where they go.
One thing that seemed like a significant API improvement was to require
that we don't build pipelines for O0. It seems to have no real benefit.
I've also switched back to returning pass managers by value as at this
API layer it feels much more natural to me for composition. But if
others disagree, I'm happy to go back to an output parameter.
I'm not 100% happy with the testing strategy currently, but it seems at
least OK. I may come back and try to refactor or otherwise improve this
in subsequent patches but I wanted to at least get a good starting point
in place.
Differential Revision: https://reviews.llvm.org/D28042
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290325 91177308-0d34-0410-b5e6-96231b3b80d8
When DwarfExpression is emitting a fragment that is located in a
register and that fragment is smaller than the register, and the
register must be composed from sub-registers (are you still with me?)
the last DW_OP_piece operation must not be larger than the size of the
fragment itself, since the last piece of the fragment could be smaller
than the last subregister that is being emitted.
rdar://problem/29779065
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290324 91177308-0d34-0410-b5e6-96231b3b80d8
There are helpers for testing for constant or constant build_vector,
and for splat ConstantFP vectors, but not for a constantfp or
non-splat ConstantFP vector.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290317 91177308-0d34-0410-b5e6-96231b3b80d8
FMA is canonicalized to constant in the middle operand. Do
the same so fmad matches and avoid an extra combine step.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290313 91177308-0d34-0410-b5e6-96231b3b80d8
This is to put the vector into a well defined state. Apparently the state of a
vector after being moved from is valid but unspecified. Found with clang-tidy.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290298 91177308-0d34-0410-b5e6-96231b3b80d8
The range metadata inserted by NVVMIntrRange is pessimistic, range
metadata already present could be more precise.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290294 91177308-0d34-0410-b5e6-96231b3b80d8
This patch renumbers the metadata nodes in debug info testcases after
https://reviews.llvm.org/D26769. This is a separate patch because it
causes so much churn. This was implemented with a python script that
pipes the testcases through llvm-as - | llvm-dis - and then goes
through the original and new output side-by side to insert all
comments at a close-enough location.
Differential Revision: https://reviews.llvm.org/D27765
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290292 91177308-0d34-0410-b5e6-96231b3b80d8
This adds a basic tablegen backend that analyzes the SelectionDAG
patterns to find simple ones that are eligible for GlobalISel-emission.
That's similar to FastISel, with one notable difference: we're not fed
ISD opcodes, so we need to map the SDNode operators to generic opcodes.
That's done using GINodeEquiv in TargetGlobalISel.td.
Otherwise, this is mostly boilerplate, and lots of filtering of any kind
of "complicated" pattern. On AArch64, this is sufficient to match G_ADD
up to s64 (to ADDWrr/ADDXrr) and G_BR (to B).
Differential Revision: https://reviews.llvm.org/D26878
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290284 91177308-0d34-0410-b5e6-96231b3b80d8
Each function summary has an attached list of type identifier GUIDs. The
idea is that during the regular LTO phase we would match these GUIDs to type
identifiers defined by the regular LTO module and store the resolutions in
a top-level "type identifier summary" (which will be implemented separately).
Differential Revision: https://reviews.llvm.org/D27967
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290280 91177308-0d34-0410-b5e6-96231b3b80d8
In order for the llvm DWARF parser to be used in LLDB we will need to be able to get the parent of a DIE. This patch adds that functionality by changing the DWARFDebugInfoEntry class to store a depth field instead of a sibling index. Using a depth field allows us to easily calculate the sibling and the parent without increasing the size of DWARFDebugInfoEntry.
I tested llvm-dsymutil on a debug version of clang where this fully parses DWARF in over 1200 .o files to verify there was no serious regression in performance.
Added a full suite of unit tests to test this functionality.
Differential Revision: https://reviews.llvm.org/D27995
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290274 91177308-0d34-0410-b5e6-96231b3b80d8
This sets USES_TERMINAL for the native llvm-config build, so that it
doesn't run at the same time as builds of other native tools (namely,
tablegen). Without this, if you're very unlucky with the timing it's
possible to be relinking libSupport as one of the tools is linking,
causing a spurious failure.
The tablegen build adopted USES_TERMINAL for this same reason in
r280748.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290271 91177308-0d34-0410-b5e6-96231b3b80d8
RTDyldMemoryManager.cpp describes the differing __register_frame
API between libunwind and libgcc, with a mailing list posting URL.
The original link was 404; replace it with what I believe is the
intended post, as well as a reference to the "OS X" implementation in
libunwind.
Differential Revision: https://reviews.llvm.org/D27965
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290269 91177308-0d34-0410-b5e6-96231b3b80d8
