| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
>32 bits.
This fixes an embarrassing bug when emitting .debug_loc entries for 64-bit+ constants,
which were previously silently truncated to 32 bits.
<rdar://problem/26843232>
llvm-svn: 273736
|
| |
|
|
| |
llvm-svn: 273733
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bitset metadata currently used in LLVM has a few problems:
1. It has the wrong name. The name "bitset" refers to an implementation
detail of one use of the metadata (i.e. its original use case, CFI).
This makes it harder to understand, as the name makes no sense in the
context of virtual call optimization.
2. It is represented using a global named metadata node, rather than
being directly associated with a global. This makes it harder to
manipulate the metadata when rebuilding global variables, summarise it
as part of ThinLTO and drop unused metadata when associated globals are
dropped. For this reason, CFI does not currently work correctly when
both CFI and vcall opt are enabled, as vcall opt needs to rebuild vtable
globals, and fails to associate metadata with the rebuilt globals. As I
understand it, the same problem could also affect ASan, which rebuilds
globals with a red zone.
This patch solves both of those problems in the following way:
1. Rename the metadata to "type metadata". This new name reflects how
the metadata is currently being used (i.e. to represent type information
for CFI and vtable opt). The new name is reflected in the name for the
associated intrinsic (llvm.type.test) and pass (LowerTypeTests).
2. Attach metadata directly to the globals that it pertains to, rather
than using the "llvm.bitsets" global metadata node as we are doing now.
This is done using the newly introduced capability to attach
metadata to global variables (r271348 and r271358).
See also: http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html
Differential Revision: http://reviews.llvm.org/D21053
llvm-svn: 273729
|
| |
|
|
|
|
| |
Patch by Lei Zhang!
llvm-svn: 273726
|
| |
|
|
|
|
| |
This patch adds round-trip support for MachO Universal binaries to obj2yaml and yaml2obj. Universal binaries have a header and list of architecture structures, followed by a the individual object files at specified offsets.
llvm-svn: 273719
|
| |
|
|
| |
llvm-svn: 273713
|
| |
|
|
|
|
|
| |
We cannot remove an instruction with no uses just because
SimplifyInstruction succeeds. It may have side effects.
llvm-svn: 273711
|
| |
|
|
|
|
| |
This makes it slightly more powerful for dynamic-no-pic.
llvm-svn: 273704
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r273608.
Broke building code with sanitizers, where apparently these kinds of
loads, casts, and truncations are common:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/24502
http://crbug.com/623099
llvm-svn: 273703
|
| |
|
|
|
|
|
|
|
|
| |
one place; NFCI
By putting all the possible commutations together, we simplify the code.
Note that this is NFCI, but I'm adding tests that actually exercise each
commutation pattern because we don't have this anywhere else.
llvm-svn: 273702
|
| |
|
|
|
|
|
|
|
| |
Tail merge was making the assumption that a layout successor or
predecessor was always a cfg successor/predecessor. Remove that
assumption. Changes to tests are necessary because the errant cfg edges
were preventing optimizations.
llvm-svn: 273700
|
| |
|
|
| |
llvm-svn: 273699
|
| |
|
|
|
|
|
|
|
|
| |
Clang emits them in reverse order to conform to the ABI, which requires
left-to-right destruction. As a result, the order doesn't fall out
naturally, and we have to sort things out in the backend.
Fixes PR28213
llvm-svn: 273696
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D21624
llvm-svn: 273692
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two remaining issues here:
1. No vbptr information
2. Need to mention indirect virtual bases
Getting indirect virtual bases is just a matter of adding an "indirect"
flag, emitting them in the frontend, and ignoring them when appropriate
for DWARF.
All virtual bases use the same artificial vbptr field, so I think the
vbptr offset will be best represented by an implicit __vbptr$ClassName
member similar to our existing __vptr$ member.
llvm-svn: 273688
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The interleaved access analysis currently assumes that the inserted run-time
pointer aliasing checks ensure the absence of dependences that would prevent
its instruction reordering. However, this is not the case.
Issues can arise from how code generation is performed for interleaved groups.
For a load group, all loads in the group are essentially moved to the location
of the first load in program order, and for a store group, all stores in the
group are moved to the location of the last store. For groups having members
involved in a dependence relation with any other instruction in the loop, this
reordering can violate the dependence.
This patch teaches the interleaved access analysis how to avoid breaking such
dependences, and should fix PR27626.
An assumption of the original analysis was that the accesses had been collected
in "program order". The analysis was then simplified by visiting the accesses
bottom-up. However, this ordering was never guaranteed for anything other than
single basic block loops. Thus, this patch also enforces the desired ordering.
Reference: https://llvm.org/bugs/show_bug.cgi?id=27626
Differential Revision: http://reviews.llvm.org/D19984
llvm-svn: 273687
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is a resubmittion of previously reverted rL273568.
This is a fix for the problem mentioned in "LTO and intrinsics mangling" llvm-dev mail thread:
http://lists.llvm.org/pipermail/llvm-dev/2016-April/098387.html
Reviewers: mehdi_amini, reames
Differential Revision: http://reviews.llvm.org/D19373
llvm-svn: 273686
|
| |
|
|
|
|
|
|
|
| |
This adds rudimentary support for COFF ARM to the dynamic loader for the
exeuction engine. This can be used by lldb to JIT code into a COFF ARM
environment. This lays the foundation for the loader, though a few of the
relocation types are yet unhandled.
llvm-svn: 273682
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D21657
llvm-svn: 273678
|
| |
|
|
| |
llvm-svn: 273669
|
| |
|
|
|
|
|
|
| |
This will do various things including ones
CodeGenPrepare does, but with knowledge of uniform
values.
llvm-svn: 273657
|
| |
|
|
|
|
| |
Hopefully the buildbots have had enough time to pick this up by now.
llvm-svn: 273656
|
| |
|
|
|
|
|
|
| |
Un XFAIL a few tests plus a few more I had lying around
in my tree, which seem to all work now but I don't see tests
that quite test the same things.
llvm-svn: 273655
|
| |
|
|
|
|
|
|
| |
The only real reason to use it is for testing, so replace
it with a command line option instead of a potentially function
dependent feature.
llvm-svn: 273653
|
| |
|
|
|
|
|
|
|
| |
They were using output streams inconsistently. One also had a grammar
bug.
I noticed these while trying to pare down D18278.
llvm-svn: 273642
|
| |
|
|
|
|
|
|
|
| |
Some buildbots are complaining about a .s file under test/ that was
inadvertently created by a test earlier today, and is still hanging
around. I'll undo this change in ~1hr (or whenever the bots are done
getting rid of said file).
llvm-svn: 273641
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
reduce the number of comparisons.
Specifically, InstCombine can turn:
(i == 5334 || i == 5335)
into:
((i | 1) == 5335)
SimplifyCFG was already able to detect the pattern:
(i == 5334 || i == 5335)
to:
((i & -2) == 5334)
This patch supersedes D21315 and resolves PR27555
(https://llvm.org/bugs/show_bug.cgi?id=27555).
Thanks to David and Chandler for the suggestions!
Author: Thomas Jablin (tjablin)
Reviewers: majnemer chandlerc halfdan cycheng
http://reviews.llvm.org/D21397
llvm-svn: 273639
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
module summary.
The function name Module::empty() is slightly misleading in that it
only tests for the presence of functions in the module. However we
still want to emit the module summary if the module contains only
global variables or aliases. The presence of such entities can be
determined simply by checking the summary directly, as we are doing
below.
Differential Revision: http://reviews.llvm.org/D21669
llvm-svn: 273638
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch also has a refactor that kills StratifiedAttr, and leaves us
with StratifiedAttrs, because having both was mildly redundant.
This patch makes us correctly handle stratified attributes when doing
interprocedural analysis. It also adds another attribute, AttrCaller,
which acts like AttrUnknown. We can filter out AttrCaller values when
during interprocedural analysis, since the caller should have
information about what arguments it's passing to its callee.
Patch by Jia Chen.
Differential Revision: http://reviews.llvm.org/D21645
llvm-svn: 273636
|
| |
|
|
|
|
|
| |
r215348 overrode the f16 libcalls to be soft-float, but
v7k uses the default (hard-float) calling convention.
llvm-svn: 273631
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We will start generating this in a future patch.
Reviewers: arsenm, kzhuravl, rafael, ruiu, tony-tye
Subscribers: arsenm, llvm-commits, kzhuravl
Differential Revision: http://reviews.llvm.org/D21482
llvm-svn: 273628
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D21655
llvm-svn: 273626
|
| |
|
|
|
|
|
|
|
|
|
|
| |
32-bit Mach headers don't have reserved fields. When generating the
mapping for 32-bit headers leaving off the reserved field will result in
parse errors if the field is present in the yaml.
Added a CHECK-NOT line to ensure that mach_header.yaml isn't adding a
reserved field, and a test to ensure that the parser error gets hit with
32-bit headers.
llvm-svn: 273623
|
| |
|
|
|
|
|
|
|
| |
Memory references were not being propagated for this folded load. This
prevented optimizations like LICM from hoisting the load.
Added test to verify that this allows LICM to proceed.
llvm-svn: 273617
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When considering whether to split an instruction with a memory operand
into an explicit load and a register-based instruction, we currently
check that the resulting instruction has exactly 1 def. This prevents 2
important LICM optimizations: compares with memory operands, and double
indirect calls. All the tests and the test-suite pass without the check.
My guess as to original intent is to limit the additional register pressure
created by the new instruction, but given that we only split out a single
register, it is already limited.
The licm-dominance test now checks actual memory loads for hoisting instead of
undef, and it tests compares.
hoist-invariant-load.ll now checks for 2 hoists, the intended hoist, and a bonus
from calling a got-relative function in a loop.
llvm-svn: 273616
|
| |
|
|
|
|
| |
With that SystemZ knows to avoid a GOT for PIE.
llvm-svn: 273614
|
| |
|
|
| |
llvm-svn: 273609
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This instcombine rule folds away trunc operations that have value available from a prior load or store.
This kind of code can be generated as a result of GVN widening the load or from source code as well.
Reviewers: reames, majnemer, sanjoy
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D21246
llvm-svn: 273608
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we just unified any arguments that seemed to be related to
each other. With this patch, we now respect dereference levels, etc.
which should make us substantially more accurate. Proper handling of
StratifiedAttrs will be done in a later patch.
Patch by Jia Chen.
Differential Revision: http://reviews.llvm.org/D21536
llvm-svn: 273596
|
| |
|
|
|
|
| |
We print those hex numbers with uppercase letters.
llvm-svn: 273594
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
X86FrameLowering::adjustForHiPEPrologue() contains a hard-coded offset
into an Erlang Runtime System-internal data structure (the PCB). As the
layout of this data structure is prone to change, this poses problems
for maintaining compatibility.
To address this problem, the compiler can produce this information as
module-level named metadata. For example (where P_NSP_LIMIT is the
offending offset):
!hipe.literals = !{ !2, !3, !4 }
!2 = !{ !"P_NSP_LIMIT", i32 152 }
!3 = !{ !"X86_LEAF_WORDS", i32 24 }
!4 = !{ !"AMD64_LEAF_WORDS", i32 24 }
Patch by Magnus Lang
Differential Revision: http://reviews.llvm.org/D20363
llvm-svn: 273593
|
| |
|
|
| |
llvm-svn: 273588
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recommiting after correcting over-eager Debug Value transfer fixing PR28270.
[DAG] Previously debug values would transfer debuginfo for the selected
start node for a replacement which allows for debug to be dropped.
Push debug value transfer to occur with node/value replacement in
SelectionDAG, remove now extraneous transfers of debug values.
This refixes PR9817 which was being incompletely checked in the
testsuite.
Reviewers: jyknight
Subscribers: dblaikie, llvm-commits
Differential Revision: http://reviews.llvm.org/D21037
llvm-svn: 273585
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
SSAT saturates an integer, making sure that its value lies within
an interval [-k, k]. Since the constant is given to SSAT as the
number of bytes set to one, k + 1 must be a power of 2, otherwise
the optimization is not possible. Also, the select_cc must use <
and > respectively so that they define an interval.
Reviewers: mcrosier, jmolloy, rengolin
Subscribers: aemerson, rengolin, llvm-commits
Differential Revision: http://reviews.llvm.org/D21372
llvm-svn: 273581
|
| |
|
|
|
|
| |
failures with rL273568.
llvm-svn: 273580
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D21630
llvm-svn: 273579
|
| |
|
|
|
|
| |
It broke 2008-07-15-Bswap.ll and 2009-09-01-PostRAProlog.ll
llvm-svn: 273574
|
| |
|
|
|
|
| |
buildbot failure
llvm-svn: 273573
|
| |
|
|
|
|
|
|
|
|
|
| |
This is a fix for the problem mentioned in "LTO and intrinsics mangling" llvm-dev mail thread:
http://lists.llvm.org/pipermail/llvm-dev/2016-April/098387.html
Reviewers: mehdi_amini, reames
Differential Revision: http://reviews.llvm.org/D19373
llvm-svn: 273568
|
| |
|
|
|
|
|
|
|
|
|
| |
When simplifying a load we need to make sure that the type of the
simplified value matches the type of the instruction we're processing.
In theory, we can handle casts here as we deal with constant data, but
since it's not implemented at the moment, we at least need to bail out.
This fixes PR28262.
llvm-svn: 273562
|