to isolate it in a dependent helper class.
Without doing this, we end up requiring all of the pointer traits the
moment you even define a PointerIntPair. That makes them *incredibly*
hard to use, for example you can't use them at all inside a class for
pointers to that class!
This change sinks all the logic into a helper template class that only
needs to be fully instantiated when *using* the PointerIntPair. We still
get compile-time checking, but it is deferred long enough to make
tradition out-of-line method definitions (or just the normal deferred
method body parsing) sufficient to handle cycling references.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256618 91177308-0d34-0410-b5e6-96231b3b80d8
If running the PlaceSafepoints pass on a module which doesn't have the
gc.safepoint_poll function without disabling entry and backedge safepoints,
previously the pass crashed with an obscure error because of a null pointer.
Now it fails the assert instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256580 91177308-0d34-0410-b5e6-96231b3b80d8
The code that was meant to adjust the duplication cost based on the
terminator opcode was not being executed in cases where the initial
threshold was hit inside the loop.
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D15536
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256568 91177308-0d34-0410-b5e6-96231b3b80d8
This is necessary to use them as part of pointer traits and is generally
useful. I've added unit test coverage to isolate and ensure this works
correctly.
I'll watch the build bots to try to see if any compilers can't tolerate
this bit of magic (and much credit goes to Richard Smith for coming up
with this magical production!) but give a shout if you see issues.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256553 91177308-0d34-0410-b5e6-96231b3b80d8
of casting the integer '4' to such a pointer. There is no reason to
expect '4' to be a portable or reliable pointer of this form. The only
reason this ever worked is because the PointerIntPair that this actually
gets used with has an artificially *low* presumed alignment that allowed
it to work. When the alignment of PointerIntPair is derived from the
actual type's alignment, the asserts start firing on this pointer. I'm
amazed we never managed to do anything that triggered the alignment
sanitizer with it, as this is just flat out UB.
If folks dislike this approach to providing a sentinel fragment address,
there are a myriad of other alternatives, suggestions welcome. But this
one has the distinct advantage of not requiring the friend dance of
ilist's sentinel (which I'll point out is *also* in play for
MCFragment!) and seems to be using a nicely provided facility in
MCFragment to establish just such dummy nodes.
This is part of a series of patches to allow LLVM to check for complete
pointee types when computing its pointer traits. This is absolutely
necessary to get correct (or reproducible) results for things like how
many low bits are guaranteed to be zero.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256552 91177308-0d34-0410-b5e6-96231b3b80d8
inline definitions after the mutually recursive pair of types have been
defined. The two types mutually recurse specifically through
abstractions that require pointer traits which makes this kind of mutual
recursion especially tricky to get right in terms of ordering.
This is part of a series of patches to allow LLVM to check for complete
pointee types when computing its pointer traits. This is absolutely
necessary to get correct (or reproducible) results for things like how
many low bits are guaranteed to be zero.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256551 91177308-0d34-0410-b5e6-96231b3b80d8
missing includes so that the pointee types for DenseMap pointer keys and
such are complete prior to us querying the pointer traits for them.
This is part of a series of patches to allow LLVM to check for complete
pointee types when computing its pointer traits. This is absolutely
necessary to get correct (or reproducible) results for things like how
many low bits are guaranteed to be zero.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256550 91177308-0d34-0410-b5e6-96231b3b80d8
used in pointer dense map key types or in other ways that require
pointer traits.
This is part of a series of patches to allow LLVM to check for complete
pointee types when computing its pointer traits. This is absolutely
necessary to get correct (or reproducible) results for things like how
many low bits are guaranteed to be zero.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256549 91177308-0d34-0410-b5e6-96231b3b80d8
header to its own header, allowing users of fragments to have a narrower
header file, and avoid circular header dependencies when getting the
definition of MCSection prior to inspecting traits on MCSection
pointers.
This is part of a series of patches to allow LLVM to check for complete
pointee types when computing its pointer traits. This is absolutely
necessary to get correct (or reproducible) results for things like how
many low bits are guaranteed to be zero.
Note that this doesn't in any way change the design of MC, it is just
moving code around to allow the *header files* to be more fine grained.
Without this, it is impossible to get a complete type for MCSection
where it is needed.
If anyone would prefer a different slicing of the header files, I'm
happy to oblige of course. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256548 91177308-0d34-0410-b5e6-96231b3b80d8
copy/pasted.
Happy for anyone to suggest a more precise or refined set of boilerplate
here, but the comments on the actual code seem descriptive and accurate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256547 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, the code enforced non-decreasing alignment of each trailing
type. However, it's easy enough to allow for realignment as needed, and
thus avoid the developer having to think about the possiblilities for
alignment requirements on all architectures.
(E.g. on Linux/x86, a struct with an int64 member is 4-byte aligned,
while on other 32-bit archs -- and even with other OSes on x86 -- it has
8-byte alignment. This sort of thing is irritating to have to manually
deal with.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256533 91177308-0d34-0410-b5e6-96231b3b80d8
That commit added a new pass, and this test is sensitive to what the
first pass after verify is called.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256532 91177308-0d34-0410-b5e6-96231b3b80d8
header.
This is part of a series of patches to allow LLVM to check for complete
pointee types when computing its pointer traits. This is absolutely
necessary to get correct (or reproducible) results for things like how
many low bits are guaranteed to be zero.
The MetadataTracking helpers aren't actually independent. They rely on
constructing a PointerUnion between Metadata and MetadataAsValue
pointers, which requires know the alignment of pointers to those types
which requires them to be complete.
The .cpp file even defined a method declared in Metadata.h! These really
don't seem like something that is separable, and there is no real
layering problem with just placing them together.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256531 91177308-0d34-0410-b5e6-96231b3b80d8
We didn't actually statically check this, and so it worked 25% of the
time for me. =/ Really sorry it took so long to fix, I shouldn't leave
the commit log editor window open without saving and landing the commit.
=[
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256528 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
* avoid generating POP {LR} in Thumb1 epilogues
* combine MOV LR, Rx + BX LR -> BX Rx in a peephole optimization pass
* combine POP {LR} + B + BX LR -> POP {PC} on v5T+
Test cases by Ana Pazos
Differential Revision: http://reviews.llvm.org/D15707
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256523 91177308-0d34-0410-b5e6-96231b3b80d8
InlineCostAnalysis is an analysis pass without any need for it to be one.
Once it stops being an analysis pass, it doesn't maintain any useful state
and the member functions inside can be made free functions. NFC.
Differential Revision: http://reviews.llvm.org/D15701
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256521 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Previously, only the outer (last) bitcast was rematerialized, resulting in a
use of the unrelocated inner (first) bitcast after the statepoint. See the
test case for an example.
Reviewers: igor-laevsky, reames
Subscribers: reames, alex, llvm-commits, sanjoy
Differential Revision: http://reviews.llvm.org/D15789
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256520 91177308-0d34-0410-b5e6-96231b3b80d8
Instead, actually produce a nonce type in the test and use that. This
makes the test, IMO, both simpler and more clear.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256518 91177308-0d34-0410-b5e6-96231b3b80d8
