These MachO file directives are used by linkers and other tools to provide
compatibility information, much like the existing .ios_version_min and
.macosx_version_min.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251569 91177308-0d34-0410-b5e6-96231b3b80d8
This teaches SCEV to compute //max// backedge taken counts for loops
like
for (int i = k; i != 0; i >>>= 1)
whatever();
SCEV yet cannot represent the exact backedge count for these loops, and
this patch does not change that. This is really geared towards teaching
SCEV that loops like the above are *not* infinite.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251558 91177308-0d34-0410-b5e6-96231b3b80d8
Add a couple of helper methods to make the primary
raw profile reader interface's implementation more
readable. It also hides more format details. This
patch has no functional change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251546 91177308-0d34-0410-b5e6-96231b3b80d8
When checking if an indirect global (a global with pointer type) is only assigned by allocation functions, first check if the global is itself initialized. If it is, it's not only assigned by allocation functions.
This fixes PR25309. Thanks to David Majnemer for reducing the test case!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251508 91177308-0d34-0410-b5e6-96231b3b80d8
Change InstrProfReaderIndex from typedef into a wrapper
class with helper methods. This makes the index profile
reader code more readable. It also hides the implementation
detail of the index format and make it more flexible to allow
support different (or more than one) format in the future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251491 91177308-0d34-0410-b5e6-96231b3b80d8
This also lets us remove the versions of the functions that took a statically sized array as we can rely on ArrayRef implicit conversion now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251490 91177308-0d34-0410-b5e6-96231b3b80d8
was causing builder failures.
The bindings were originally added in r251472, and reverted in r251473 due to
the builder failures.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251482 91177308-0d34-0410-b5e6-96231b3b80d8
r248010 changed the -debug output to use short ids, but did not
similarly modify the graph printer. Change to be consistent, for ease of
cross-reference.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251465 91177308-0d34-0410-b5e6-96231b3b80d8
Use 10 bits to represent calling convention ID's instead of 13, and
update the bitcode compatibility tests accordingly. We now error-out in
the bitcode reader when we see bad calling conv ID's.
Thanks to rnk and dexonsmith for feedback!
Differential Revision: http://reviews.llvm.org/D13826
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251452 91177308-0d34-0410-b5e6-96231b3b80d8
AliasSetTracker does not need to convert the access mode to ModRefAccess if the
new visited UnknownInst has only 'REF' modrefinfo to existing pointers in the
sets.
Patch by Andrew Zhogin!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251451 91177308-0d34-0410-b5e6-96231b3b80d8
When optimization is disabled, edge weights that are stored in MBB won't be used so that we don't have to store them. Currently, this is done by adding successors with default weight 0, and if all successors have default weights, the weight list will be empty. But that the weight list is empty doesn't mean disabled optimization (as is stated several times in MachineBasicBlock.cpp): it may also mean all successors just have default weights.
We should discourage using default weights when adding successors, because it is very easy for users to forget update the correct edge weights instead of using default ones (one exception is that the MBB only has one successor). In order to detect such usages, it is better to differentiate using default weights from the case when optimizations is disabled.
In this patch, a new interface addSuccessorWithoutWeight(MBB*) is created for when optimization is disabled. In this case, MBB will try to maintain an empty weight list, but it cannot guarantee this as for many uses of addSuccessor() whether optimization is disabled or not is not checked. But it can guarantee that if optimization is enabled, then the weight list always has the same size of the successor list.
Differential revision: http://reviews.llvm.org/D13963
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251429 91177308-0d34-0410-b5e6-96231b3b80d8
This avoid mentioning the table name an extra time and allows the lookup to be done directly in the ifs by relying on the bool conversion of the pointer.
While there make use of ArrayRef and std::find_if.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251382 91177308-0d34-0410-b5e6-96231b3b80d8
LLVMSymbolizer::Options is mostly used in LLVMSymbolizer class anyway.
Let's keep their usage restricted to that class, especially given that
it's worth to move ModuleInfo to a different header, independent from
the symbolizer class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251363 91177308-0d34-0410-b5e6-96231b3b80d8
Processing bitcode from a different LLVM version can lead to
unexpected behavior. The LLVM project guarantees autoupdating
bitcode from a previous minor revision for the same major, but
can't make any promise when reading bitcode generated from a
either a non-released LLVM, a vendor toolchain, or a "future"
LLVM release. This patch aims at being more user-friendly and
allows a bitcode produce to emit an optional block at the
beginning of the bitcode that will contains an opaque string
intended to describe the bitcode producer information. The
bitcode reader will dump this information alongside any error it
reports.
The optional block also includes an "epoch" number, monotonically
increasing when incompatible changes are made to the bitcode. The
reader will reject bitcode whose epoch is different from the one
expected.
Differential Revision: http://reviews.llvm.org/D13666
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251325 91177308-0d34-0410-b5e6-96231b3b80d8
Android libc provides a fixed TLS slot for the unsafe stack pointer,
and this change implements direct access to that slot on AArch64 via
__builtin_thread_pointer() + offset.
This change also moves more code into TargetLowering and its
target-specific subclasses to get rid of target-specific codegen
in SafeStackPass.
This change does not touch the ARM backend because ARM lowers
builting_thread_pointer as aeabi_read_tp, which is not available
on Android.
The previous iteration of this change was reverted in r250461. This
version leaves the generic, compiler-rt based implementation in
SafeStack.cpp instead of moving it to TargetLoweringBase in order to
allow testing without a TargetMachine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251324 91177308-0d34-0410-b5e6-96231b3b80d8
We were previously overflowing a 32-bit multiply operation when emitting large
(>512MB) bitcode files, resulting in corrupted bitcode. Fix by extending
one of the operands to 64 bits.
There are a few other 32-bit integer types in this code that seem like they
also ought to be extended to 64 bits; this will be done separately.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251323 91177308-0d34-0410-b5e6-96231b3b80d8
In PIC mode we were previously computing global variable addresses (or GOT
entry addresses) by adding the PC, the PC-relative GOT displacement and
the GOT-relative symbol/GOT entry displacement. Because the latter two
displacements are fixed, we ended up performing one more addition than
necessary.
This change causes us to compute addresses using a single PC-relative
displacement, resulting in a shorter code sequence. This reduces code size
by about 4% in a recent build of Chromium for Android.
As a result of this change we no longer need to compute the GOT base address
in the ARM backend, which allows us to remove the Global Base Reg pass and
SDAG lowering for the GOT.
We also now no longer use the GOT when addressing a symbol which is known
to be defined in the same linkage unit. Specifically, the symbol must have
either hidden visibility or a strong definition in the current module in
order to not use the the GOT.
This is a change from the previous behaviour where we would use the GOT to
address externally visible symbols defined in the same module. I think the
only cases where this could matter are cases involving symbol interposition,
but we don't really support that well anyway.
Differential Revision: http://reviews.llvm.org/D13650
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251322 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Replace (const SCEVAddRecExpr *) with cast<SCEVAddRecExpr>.
Rename SCEVApplyRewriter to SCEVLoopAddRecRewriter (which is a more
appropriate name) since the description is "takes a scalar evolution
expression and applies the Map (Loop -> SCEV) to all AddRecExprs."
Subscribers: llvm-commits, sanjoy
Differential Revision: http://reviews.llvm.org/D14065
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251292 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Add a SCEVRewriteVisitor class which contains the common
visiting patterns used when rewriting SCEVs.
SCEVParameterRewriter and SCEVApplyRewriter now inherit
from SCEVRewriteVisitor (and are therefore much simpler).
Reviewers: anemet, mzolotukhin, sanjoy
Subscribers: rengolin, llvm-commits, sanjoy
Differential Revision: http://reviews.llvm.org/D13242
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251283 91177308-0d34-0410-b5e6-96231b3b80d8
the module pointer type passed in by the user.
The previous ownership scheme, where the user pointer was always moved into a
std::shared_ptr, breaks if the user passes in a raw pointer.
Discovered while working on the Orc C API, which should be landing shortly.
I expect to include a test-case with that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251273 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of playing around with dominance to verify if the possible expansion of
a scop region is indeed a single entry single exit region, we now distinguish
two cases. In case we only append a basic block, all edges entering this basic
block need to have come from within the region that is expanded. In case we join
two regions, the source basic blocks of the edges that end at the entry node of
the region that is appended most be part of either the original region or the
region that is appended.
This change will be tested through Polly.
This fixes llvm.org/PR25242
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251267 91177308-0d34-0410-b5e6-96231b3b80d8
When the target does not support these intrinsics they should be converted to a chain of scalar load or store operations.
If the mask is not constant, the scalarizer will build a chain of conditional basic blocks.
I added isLegalMaskedGather() isLegalMaskedScatter() APIs.
Differential Revision: http://reviews.llvm.org/D13722
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251237 91177308-0d34-0410-b5e6-96231b3b80d8
When using the MCU psABI, compiler-generated library calls should pass
some parameters in-register. However, since inreg marking for x86 is currently
done by the front end, it will not be applied to backend-generated calls.
This is a workaround for PR3997, which describes a similar issue for -mregparm.
Differential Revision: http://reviews.llvm.org/D13977
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251223 91177308-0d34-0410-b5e6-96231b3b80d8
I think it's fine to keep this fields around in terms of overhead,
I wasn't able to measure any substantial regression while running the
test suite, but, in case this causes some regression I'm ready to revert
and work on an alternative solution.
This was tested building with clang/gcc both in Debug and Release mode
and passes the test-suite.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251209 91177308-0d34-0410-b5e6-96231b3b80d8
The loop idiom creating a ConstantRange is repeated twice in the
codebase, time to give it a name and a home.
The loop is also repeated in `rangeMetadataExcludesValue`, but using
`getConstantRangeFromMetadata` there would not be an NFC -- the range
returned by `getConstantRangeFromMetadata` may contain a value that none
of the subranges did.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251180 91177308-0d34-0410-b5e6-96231b3b80d8
In this mode it just tries to tail merge the strings without imposing any other
format constrains. It will not, for example, add a null byte between them.
Also add support for keeping a tentative size and offset if we decide to
not optimize after all.
This will be used shortly in lld for merging SHF_STRINGS sections.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@251153 91177308-0d34-0410-b5e6-96231b3b80d8
