Summary:
In rL291613, the section name was interned in LLVMContext. However,
this broke the ability to remove the section from a GlobalObject,
because it tried to intern empty strings, which is not allowed.
Fix that and add an appropriate regression test.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D29795
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@295238 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r294617.
We fail on an assert while trying to get a condition from an
unconditional branch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@295200 91177308-0d34-0410-b5e6-96231b3b80d8
Unit tests needed to check on the endianness of the host platform. (Test was failing for big endian hosts).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@295174 91177308-0d34-0410-b5e6-96231b3b80d8
Changed format specifiers to use format macro constant for pointer type.
Moved width part of format specifier in the correct place for formatting members a and b.
Added a unit test to confirm the output.
Differential Revision: https://reviews.llvm.org/D28957
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@295173 91177308-0d34-0410-b5e6-96231b3b80d8
handler args.
The specialization just inherits from the std::decay'd response handler type.
This allows member functions (via MemberFunctionWrapper) to be used as async
handlers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@295151 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is achieved by generalizing the expression selecting the StringRef
format_provider. Now, anything that can be converted to a StringRef will
use it's formatter.
Reviewers: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29898
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@295064 91177308-0d34-0410-b5e6-96231b3b80d8
Launch policies provided a mechanism for running RPC handlers on a background
thread (unblocking the main RPC receiver thread). Async handlers generalize
this by passing the responder function (the function that sends the RPC return
value) as an argument to the handler. The handler can optionally do its work on
a background thread (the same way launch policies do), but can also (a) can
inspect the call arguments before deciding to run the work on a different
thread, or (b) can use the responder in a subsequent RPC call (e.g. in the
handler of a callAsync), allowing the handler to call back to the originator (or
to a 3rd party) without blocking the listener thread, and without launching a
new thread.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@295030 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In preparation for graph comparison and filtering, this is a library for
representing graphs in LLVM. This will enable easier encapsulation and reuse
of graphs in llvm-xray.
Depends on D28999, D28225
Reviewers: dblaikie, dberris
Reviewed By: dberris
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29005
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294717 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In preparation for graph comparison and filtering, this is a library for
representing graphs in LLVM. This will enable easier encapsulation and reuse
of graphs in llvm-xray.
Depends on D28999, D28225
Reviewers: dblaikie, dberris
Reviewed By: dberris
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29005
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294713 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM defines `PTHREAD_LIB` which is used by AddLLVM.cmake and various projects
to correctly link the threading library when needed. Unfortunately
`PTHREAD_LIB` is defined by LLVM's `config-ix.cmake` file which isn't installed
and therefore can't be used when configuring out-of-tree builds. This causes
such builds to fail since `pthread` isn't being correctly linked.
This patch attempts to fix that problem by renaming and exporting
`LLVM_PTHREAD_LIB` as part of`LLVMConfig.cmake`. I renamed `PTHREAD_LIB`
because It seemed likely to cause collisions with downstream users of
`LLVMConfig.cmake`.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294690 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for padded SLEB128 values, and support for writing SLEB128
values to buffers rather than to ostreams, similar to the existing
ULEB128 support.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294675 91177308-0d34-0410-b5e6-96231b3b80d8
Somewhat amazingly, this only requires teaching it to clean them up when
deleting a dead function from the graph. And we already have exactly the
necessary data structures to do that in the parent RefSCCs.
This allows ArgPromote to work in a much simpler way be merely letting
reference edges linger in the graph after the causing IR is deleted. We
will clean up these edges when we run any function pass over the IR, but
don't remove them eagerly.
This avoids all of the quadratic update issues both in the current pass
manager and in my previous attempt with the new pass manager.
Differential Revision: https://reviews.llvm.org/D29579
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294663 91177308-0d34-0410-b5e6-96231b3b80d8
Gcc supports target armv7ve which is armv7-a with virtualization
extensions. This change adds support for this in llvm for gcc
compatibility.
Also remove redundant FeatureHWDiv, FeatureHWDivARM for a few models as
this is specified automatically by FeatureVirtualization.
Patch by Manoj Gupta.
Differential Revision: https://reviews.llvm.org/D29472
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294661 91177308-0d34-0410-b5e6-96231b3b80d8
disturbing the graph or having to update edges.
This is motivated by porting argument promotion to the new pass manager.
Because of how LLVM IR Function objects work, in order to change their
signature a new object needs to be created. This is efficient and
straight forward in the IR but previously was very hard to implement in
LCG. We could easily replace the function a node in the graph
represents. The challenging part is how to handle updating the edges in
the graph.
LCG previously used an edge to a raw function to represent a node that
had not yet been scanned for calls and references. This was the core
of its laziness. However, that model causes this kind of update to be
very hard:
1) The keys to lookup an edge need to be `Function*`s that would all
need to be updated when we update the node.
2) There will be some unknown number of edges that haven't transitioned
from `Function*` edges to `Node*` edges.
All of this complexity isn't necessary. Instead, we can always build
a node around any function, always pointing edges at it and always using
it as the key to lookup an edge. To maintain the laziness, we need to
sink the *edges* of a node into a secondary object and explicitly model
transitioning a node from empty to populated by scanning the function.
This design seems much cleaner in a number of ways, but importantly
there is now exactly *one* place where the `Function*` has to be
updated!
Some other cleanups that fall out of this include having something to
model the *entry* edges more accurately. Rather than hand rolling parts
of the node in the graph itself, we have an explicit `EdgeSequence`
object that gives us exactly the functionality needed. We also have
a consistent place to define the edge iterators and can use them for
both the entry edges and the internal edges of the graph.
The API used to model the separation between a node and its edges is
intentionally very thin as most clients are expected to deal with nodes
that have populated edges. We model this exactly as an optional does
with an additional method to populate the edges when that is
a reasonable thing for a client to do. This is based on API design
suggestions from Richard Smith and David Blaikie, credit goes to them
for helping pick how to model this without it being either too explicit
or too implicit.
The patch is somewhat noisy due to shifting around iterator types and
new syntax for walking the edges of a node, but most of the
functionality change is in the `Edge`, `EdgeSequence`, and `Node` types.
Differential Revision: https://reviews.llvm.org/D29577
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294653 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch allows JumpThreading also thread through guards.
Virtually, guard(cond) is equivalent to the following construction:
if (cond) { do something } else {deoptimize}
Yet it is not explicitly converted into IFs before lowering.
This patch enables early threading through guards in simple cases.
Currently it covers the following situation:
if (cond1) {
// code A
} else {
// code B
}
// code C
guard(cond2)
// code D
If there is implication cond1 => cond2 or !cond1 => cond2, we can transform
this construction into the following:
if (cond1) {
// code A
// code C
} else {
// code B
// code C
guard(cond2)
}
// code D
Thus, removing the guard from one of execution branches.
Patch by Max Kazantsev!
Reviewers: reames, apilipenko, igor-laevsky, anna, sanjoy
Reviewed By: sanjoy
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29620
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294617 91177308-0d34-0410-b5e6-96231b3b80d8
Add explicit conversions between forward and reverse ilist iterators.
These follow the conversion conventions of std::reverse_iterator, which
are off-by-one: the newly-constructed "reverse" iterator dereferences to
the previous node of the one sent in. This has the benefit of
converting reverse ranges in place:
- If [I, E) is a valid range,
- then [reverse(E), reverse(I)) gives the same range in reverse order.
ilist_iterator::getReverse() is unchanged: it returns a reverse iterator
to the *same* node.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294349 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The formatter has three knobs:
- the user can choose which time unit to use for formatting (default: whatever is the unit of the input)
- he can choose whether the unit gets displayed (default: yes)
- he can affect the way the number itself is formatted via standard number formatting options (default:default)
Reviewers: zturner, inglorion
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29481
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294326 91177308-0d34-0410-b5e6-96231b3b80d8
into CRTP base classes.
This can sometimes happen and not cause an immediate failure when the
derived class is, itself, a template. You can end up essentially calling
methods on the wrong derived type but a type where many things will
appear to "work".
To fail fast and with a clear error message we can use a static_assert,
but we have to stash that static_assert inside a method body or nested
type that won't need to be completed while building the base class. I've
tried to pick a reasonably small number of places that seemed like they
would definitely get triggered on use.
This is the last of the patch series defending against this that I have
planned, so far no bugs other than the original were found.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294275 91177308-0d34-0410-b5e6-96231b3b80d8
SCEV.
This test was immediately the slowest test in 'check-llvm' even in an
optimized build and was driving up the total test time by 50% for me.
Sanjoy has filed a PR about the quadratic behavior in SCEV but it is
also concerning that the test still passes given that r294181 added
a threshold at 32 to SCEV. I've followed up on the original patch to
figure out how this test should work long-term, but for now I want to
get check-llvm to be fast again.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294241 91177308-0d34-0410-b5e6-96231b3b80d8
iteration.
The lazy formation of RefSCCs isn't really the most important part of
the laziness here -- that has to do with walking the functions
themselves -- and isn't essential to maintain. Originally, there were
incremental update algorithms that relied on updates happening
predominantly near the most recent RefSCC formed, but those have been
replaced with ones that have much tighter general case bounds at this
point. We do still perform asserts that only scale well due to this
incrementality, but those are easy to place behind EXPENSIVE_CHECKS.
Removing this simplifies the entire analysis by having a single up-front
step that builds all of the RefSCCs in a direct Tarjan walk. We can even
easily replace this with other or better algorithms at will and with
much less confusion now that there is no iterator-based incremental
logic involved. This removes a lot of complexity from LCG.
Another advantage of moving in this direction is that it simplifies
testing the system substantially as we no longer have to worry about
observing and mutating the graph half-way through the RefSCC formation.
We still need a somewhat special iterator for RefSCCs because we want
the iterator to remain stable in the face of graph updates. However,
this now merely involves relative indexing to the current RefSCC's
position in the sequence which isn't too hard.
Differential Revision: https://reviews.llvm.org/D29381
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294227 91177308-0d34-0410-b5e6-96231b3b80d8
for a quite big function with source like
%add = add nsw i32 %mul, %conv
%mul1 = mul nsw i32 %add, %conv
%add2 = add nsw i32 %mul1, %add
%mul3 = mul nsw i32 %add2, %add
; repeat couple of thousands times
that can be produced by loop unroll, getAddExpr() tries to recursively construct SCEV and runs almost infinite time.
Added recursion depth restriction (with new parameter to set it)
Reviewers: sanjoy
Subscribers: hfinkel, llvm-commits, mzolotukhin
Differential Revision: https://reviews.llvm.org/D28158
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294181 91177308-0d34-0410-b5e6-96231b3b80d8
Triple::objectFormat defaults to an Elf format.
Changing objectFormat to Elf doesn't make any difference.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294104 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: As per title. I ran into that limitation of the API doing some other work, so I though that'd be a nice addition.
Reviewers: jroelofs, compnerd, majnemer
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29503
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294063 91177308-0d34-0410-b5e6-96231b3b80d8
If LLVM was configured with an x86_64-apple-macosx host triple, this
test would fail, as the API works but the triple isn't in the whitelist.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293990 91177308-0d34-0410-b5e6-96231b3b80d8
Add both cores to the target parser and TableGen. Test that eabi
attributes are set correctly for both cores. Additionally, test the
absence and presence of MOVT in Cortex-M23 and Cortex-M33, respectively.
Committed on behalf of Sanne Wouda.
Reviewers : rengolin, olista01.
Differential Revision: https://reviews.llvm.org/D29073
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293761 91177308-0d34-0410-b5e6-96231b3b80d8
insertUse, moveBefore and moveAfter operations.
Summary:
This creates a basic MemorySSA updater that handles arbitrary
insertion of uses and defs into MemorySSA, as well as arbitrary
movement around the CFG. It replaces the current splice API.
It can be made to handle arbitrary control flow changes.
Currently, it uses the same updater algorithm from D28934.
The main difference is because MemorySSA is single variable, we have
the complete def and use list, and don't need anyone to give it to us
as part of the API. We also have to rename stores below us in some
cases.
If we go that direction in that patch, i will merge all the updater
implementations (using an updater_traits or something to provide the
get* functions we use, called read*/write* in that patch).
Sadly, the current SSAUpdater algorithm is way too slow to use for
what we are doing here.
I have updated the tests we have to basically build memoryssa
incrementally using the updater api, and make sure it still comes out
the same.
Reviewers: george.burgess.iv
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29047
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293356 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293085 91177308-0d34-0410-b5e6-96231b3b80d8
AssertingVH that delays any reported error until the handle is *used*.
This allows data structures to contain handles which become dangling
provided the data structure is cleaned up afterward rather than used for
anything interesting.
The implementation is moderately horrible in part because it works to
leave AssertingVH in place, undisturbed. If at some point there is
consensus that this is simply how AssertingVH should be used, it can be
substantially simplified.
This remains a boring pointer in a non-asserts build as you would
expect. The only place we pay cost is in asserts builds.
I plan to use this as a basis for replacing the asserting VHs that
currently dangle in the new PM until invalidation occurs in both LVI and
SCEV.
Differential Revision: https://reviews.llvm.org/D29061
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292925 91177308-0d34-0410-b5e6-96231b3b80d8
The test fails when there is a symlink on the path because then the path
returned by current_path will not match the one we have set. Instead of
doing a string match check the unique id of the two files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292916 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This adds a cross-platform way of setting the current working directory
analogous to the existing current_path() function used for retrieving
it. The function will be used in lldb.
Reviewers: rafael, silvas, zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29035
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292907 91177308-0d34-0410-b5e6-96231b3b80d8
