This adds 4 new functions to StringRef, which can be used to
take or drop characters while a certain condition is met, or
until a certain condition is met. They are:
take_while - Return characters until a condition is not met.
take_until - Return characters until a condition is met.
drop_while - Remove characters until a condition is not met.
drop_until - Remove characters until a condition is met.
Internally, all of these functions delegate to two additional
helper functions which can be used to search for the position
of a character meeting or not meeting a condition, which are:
find_if - Find the first character matching a predicate.
find_if_not - Find the first character not matching a predicate.
Differential Revision: https://reviews.llvm.org/D24842
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282346 91177308-0d34-0410-b5e6-96231b3b80d8
Stop looking at users of UndefValue and ConstantPointerNull in the
objective C ARC optimizers. The other users aren't actually
interesting, since they're not pointing at a particular object. I
imagine these calls could be optimized through -instcombine... maybe
they already are?
These early returns will be required at some point in the future, with a
WIP patch that asserts when someone accesses a use-list on ConstantData.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282338 91177308-0d34-0410-b5e6-96231b3b80d8
There is no benefit in looking through assumptions on UndefValue to
guess known bits. Return early to avoid walking their use-lists, and
assert that all instances of ConstantData are handled here for similar
reasons (UndefValue was the only integer/pointer holdout).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282337 91177308-0d34-0410-b5e6-96231b3b80d8
Assumptions on UndefValue and ConstantPointerNull aren't relevant to
other users. Ignore them entirely to avoid wasting cycles walking
through their (possibly extremely extensive (cross-module)) use-lists.
It wasn't clear how to add a specific test for this, and it'll be
covered anyway by an eventual patch that asserts when trying to access
the use-list of an instance of ConstantData.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282334 91177308-0d34-0410-b5e6-96231b3b80d8
Check and return early for ConstantPointerNull and UndefValue
specifically in isKnownNonNullAt, and assert that ConstantData never
make it to isKnownNonNullFromDominatingCondition.
This confirms that isKnownNonNullFromDominatingCondition never walks
through the use-list of an instance of ConstantData. Given that such
use-lists cross module boundaries, it never really made sense to do so,
and was potentially very expensive.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282333 91177308-0d34-0410-b5e6-96231b3b80d8
This adds a comment explaining why we will duplicate PartialMapping to
represent the breakdown for complex mappings (mappings with more than
one partial mapping), instead of using an array of pointer.
NFC
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282326 91177308-0d34-0410-b5e6-96231b3b80d8
Like partial mappings, as we move toward TableGen'ed information, the
number should reach zero eventually.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282325 91177308-0d34-0410-b5e6-96231b3b80d8
This is a step toward statically allocate ValueMapping. Like the
previous few commits, the goal is to move toward a TableGen'ed like
structure with no dynamic allocation at all.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282324 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we were using the address of the unique instance of a partial
mapping in the related map to access this instance. However, when the
map grows, the whole set of instances may be moved elsewhere and the
previous addresses are not valid anymore.
Instead, keep the address of the unique heap allocated instance of a
partial mapping.
Note: I did not see any actual bugs for that problem as the number of
partial mappings dynamically allocated is small (<= 4).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282323 91177308-0d34-0410-b5e6-96231b3b80d8
Return early from llvm::isSafeToDestroyConstant() whenever the value
`isa<ConstantData>()`. These constants are shared across the
LLVMContext. We never really want to delete them here, and walking
their use-lists can be very expensive.
(This is motivated by an eventual goal of removing use-lists entirely
from ConstantData.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282320 91177308-0d34-0410-b5e6-96231b3b80d8
This is similar to:
https://reviews.llvm.org/rL279958
By not prematurely lowering to loads, we should be able to more easily eliminate
the 'or' with zero instructions seen in copysign-constant-magnitude.ll.
We should also be able to extend this code to handle vectors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282312 91177308-0d34-0410-b5e6-96231b3b80d8
The NativeObjectOutput class has a design problem: it mixes up the caching
policy with the interface for output streams, which makes the client-side
code hard to follow and would for example make it harder to replace the
cache implementation in an arbitrary client.
This change separates the two aspects by moving the caching policy
to a separate field in Config, replacing NativeObjectOutput with a
NativeObjectStream class which only deals with streams and does not need to
be overridden by most clients and introducing an AddFile callback for adding
files (e.g. from the cache) to the link.
Differential Revision: https://reviews.llvm.org/D24622
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282299 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
As suggested in D24826, use different options for ThinLTO backend
parallelism from the option controlling regular LTO code gen
parallelism. They are already split in the LTO API, and this enables
controlling them with different clang options.
Reviewers: pcc, mehdi_amini
Subscribers: dexonsmith, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D24873
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282290 91177308-0d34-0410-b5e6-96231b3b80d8
... so that they don't show up in the index. This came up because polly
contains a .git directory and some other unmapped input in its source
dir.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282282 91177308-0d34-0410-b5e6-96231b3b80d8
We used to append filenames into a vector of std::string, and then
append a reference to each string into a separate vector. This made it
easier to work with the getUniqueSourceFiles API. But it's buggy.
std::string has a small-string optimization, so you can't expect to
capture a reference to one if you're copying it into a growing vector.
Add a test that triggers this invalid reference to std::string scenario,
and kill the issue with fire by just using ArrayRef<std::string>
everywhere.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282281 91177308-0d34-0410-b5e6-96231b3b80d8
As the development of GlobalISel move forward, this statistic should
strictly decrease until it reaches zero. At this point, it would mean
GlobalISel can replace SDISel (at least on the tested inputs :P).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282275 91177308-0d34-0410-b5e6-96231b3b80d8
Collect statistics about the number of partial mappings dynamically
allocated and accessed. Ultimately, when the whole TableGen
infrastructure is set, those numbers should be zero.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282274 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: When identifying cold blocks, consider only the edge to the normal destination if the terminator is InvokeInst and let calcInvokeHeuristics() decide edge weights for the InvokeInst.
Reviewers: mcrosier, hfinkel, davidxl
Subscribers: mcrosier, llvm-commits
Differential Revision: https://reviews.llvm.org/D24868
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282262 91177308-0d34-0410-b5e6-96231b3b80d8
If a constant is unamed_addr and is only used within one function, we can save
on the code size and runtime cost of an indirection by changing the global's storage
to inside the constant pool. For example, instead of:
ldr r0, .CPI0
bl printf
bx lr
.CPI0: &format_string
format_string: .asciz "hello, world!\n"
We can emit:
adr r0, .CPI0
bl printf
bx lr
.CPI0: .asciz "hello, world!\n"
This can cause significant code size savings when many small strings are used in one
function (4 bytes per string).
This recommit contains fixes for a nasty bug related to fast-isel fallback - because
fast-isel doesn't know about this optimization, if it runs and emits references to
a string that we inline (because fast-isel fell back to SDAG) we will end up
with an inlined string and also an out-of-line string, and we won't emit the
out-of-line string, causing backend failures.
It also contains fixes for emitting .text relocations which made the sanitizer
bots unhappy.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@282241 91177308-0d34-0410-b5e6-96231b3b80d8
