| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 257885
|
|
|
|
| |
llvm-svn: 257884
|
|
|
|
| |
llvm-svn: 257883
|
|
|
|
| |
llvm-svn: 257882
|
|
|
|
| |
llvm-svn: 257881
|
|
|
|
| |
llvm-svn: 257880
|
|
|
|
| |
llvm-svn: 257879
|
|
|
|
| |
llvm-svn: 257878
|
|
|
|
|
|
| |
features
llvm-svn: 257877
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are several requirements that ended up with this design;
1. Matching bitreversals is too heavyweight for InstCombine and doesn't really need to be done so early.
2. Bitreversals and byteswaps are very related in their matching logic.
3. We want to implement support for matching more advanced bswap/bitreverse patterns like partial bswaps/bitreverses.
4. Bswaps are best matched early in InstCombine.
The result of these is that a new utility function is created in Transforms/Utils/Local.h that can be configured to search for bswaps, bitreverses or both. InstCombine uses it to find only bswaps, CGP uses it to find only bitreversals.
We can then extend the matching logic in one place only.
llvm-svn: 257875
|
|
|
|
|
|
|
|
| |
SLGBR -> SLBGR
Reviewed by Ulrich Weigand
llvm-svn: 257874
|
|
|
|
|
|
| |
separate flag (-use_memcmp, default=1)
llvm-svn: 257873
|
|
|
|
|
|
|
|
|
|
|
| |
This method has no callers.
Also remove X86ELFRelocationInfo.cpp and X86MachORelocationInfo.cpp
which only existed to provide an implementation of that method.
Ok'd by Rafael and Jim.
llvm-svn: 257859
|
|
|
|
|
|
|
|
|
| |
Yet another wave of buildbot failures (though fewer this time).
I'm only reverting the Verifier changes, as the test cases
will be fine without them as well, and touching them as often
just introduces unnecessary churn.
llvm-svn: 257855
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I originally reapplied this in 257550, but had to revert again due to bot
breakage. The only change in this version is to allow either the TypeSize
or the TypeAllocSize of the variable to be the one represented in debug info
(hopefully in the future we can figure out how to encode the difference).
Additionally, several bot failures following r257550, were due to
optimizer bugs now fixed in r257787 and r257795.
r257550 commit message was:
```
The follow extra changes were made to test cases:
Manually making the variable be the actual type instead of a pointer
to avoid pointer-size differences in generic code:
LLVM :: DebugInfo/Generic/2010-03-24-MemberFn.ll
LLVM :: DebugInfo/Generic/2010-04-06-NestedFnDbgInfo.ll
LLVM :: DebugInfo/Generic/2010-05-03-DisableFramePtr.ll
LLVM :: DebugInfo/Generic/varargs.ll
Delete sizing information from debug info for the same reason
(but the presence of the pointer was important to the test case):
LLVM :: DebugInfo/Generic/restrict.ll
LLVM :: DebugInfo/Generic/tu-composite.ll
LLVM :: Linker/type-unique-type-array-a.ll
LLVM :: Linker/type-unique-simple2.ll
Fixing an incorrect DW_OP_deref
LLVM :: DebugInfo/Generic/2010-05-03-OriginDIE.ll
Fixing a missing DW_OP_deref
LLVM :: DebugInfo/Generic/incorrect-variable-debugloc.ll
Additionally, clang should no longer complain during bootstrap should no
longer happen after r257534.
The original commit message was:
``
Summary:
Teach the Verifier to make sure that the storage size given to llvm.dbg.declare
or the value size given to llvm.dbg.value agree with what is declared in
DebugInfo. This is implicitly assumed in a number of passes (e.g. in SROA).
Additionally this catches a number of common mistakes, such as passing a
pointer when a value was intended or vice versa.
One complication comes from stack coloring which modifies the original IR when
it merges allocas in order to make sure that if AA falls back to the IR it gets
the correct result. However, given this new invariant, indiscriminately
replacing one alloca by a different (differently sized one) is no longer valid.
Fix this by just undefing out any use of the alloca in a dbg.declare in this
case.
Additionally, I had to fix a number of test cases. Of particular note:
- I regenerated dbg-changes-codegen-branch-folding.ll from the given source as
it was affected by the bug fixed in r256077
- two-cus-from-same-file.ll was changed to avoid having a variable-typed debug
variable as that would depend on the target, even though this test is
supposed to be generic
- I had to manually declared size/align for reference type. See also the
discussion for D14275/r253186.
- fpstack-debuginstr-kill.ll required changing `double` to `long double`
- most others were just a question of adding OP_deref
``
```
llvm-svn: 257850
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Since you cannot call finalizeObject manually through the C-API and other functions from the C-API automatically call it, LLVMRunStaticConstructors should also call it or otherwise you cannot call it without first calling a workaround function (or call any other function from the C-API which implicitly finalizes the object).
Reviewers: dnovillo, spatel, bkramer, deadalnix, joker.eph, echristo, lhames
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16188
llvm-svn: 257849
|
|
|
|
|
|
| |
users can check for its presence.
llvm-svn: 257848
|
|
|
|
| |
llvm-svn: 257845
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This pass may modify the Cmp operands. However, the flag reg may be used by both the branch and CSEL.
Modifying CMP will have side effect on CSEL.
Reviewers: t.p.northover
Subscribers: llvm-commits, aemerson, rengolin
Differential Revision: http://reviews.llvm.org/D16147
llvm-svn: 257844
|
|
|
|
| |
llvm-svn: 257835
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D15401
llvm-svn: 257832
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Before this the Verifier didn't complain if the GlobalVariable
referenced from a DIGlobalVariable was not in fact in the correct
module (it would crash while writing bitcode though). Fix this by
always checking parantage of GlobalValues while walking constant
expressions and changing the DIGlobalVariable visitor to also
visit the constant it contains.
Reviewers: rafael
Differential Revision: http://reviews.llvm.org/D16059
llvm-svn: 257825
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We already have the inverse verification that we only use globals
that are defined in this module. This essentially catches the
same mistake, but when verifying the module that contains the
definition.
Reviewers: rafael
Differential Revision: http://reviews.llvm.org/D15272
llvm-svn: 257823
|
|
|
|
| |
llvm-svn: 257819
|
|
|
|
|
|
|
|
|
| |
classes.
OrcRemoteTargetClient::RCMemoryManager will now register EH frames with the
server automatically. This allows remote-execution of code that uses exceptions.
llvm-svn: 257816
|
|
|
|
| |
llvm-svn: 257815
|
|
|
|
| |
llvm-svn: 257811
|
|
|
|
| |
llvm-svn: 257805
|
|
|
|
| |
llvm-svn: 257804
|
|
|
|
|
|
|
| |
David Majnemer noticed that it was not obvious what the behavior would
be if B.Offset - A.Offset could not fit in an int.
llvm-svn: 257803
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch seeds the SLP vectorizer with getelementptr indices. The primary
motivation in doing so is to vectorize gather-like idioms beginning with
consecutive loads (e.g., g[a[0] - b[0]] + g[a[1] - b[1]] + ...). While these
cases could be vectorized with a top-down phase, seeding the existing bottom-up
phase with the index computations avoids the complexity, compile-time, and
phase ordering issues associated with a full top-down pass. Only bundles of
single-index getelementptrs with non-constant differences are considered for
vectorization.
Differential Revision: http://reviews.llvm.org/D14829
llvm-svn: 257800
|
|
|
|
|
|
| |
Thanks to David Blaikie for noticing it.
llvm-svn: 257796
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: If SROA creates only one piece (e.g. because the other is not needed),
it still needs to create a bit_piece expression if that bit piece is smaller
than the original size of the alloca.
Reviewers: aprantl
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16187
llvm-svn: 257795
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since r230276, we support an improved legalization for f64->f16,
which goes through a temporary f32, improving codegen when
f32->f16 is legal but not f64->f16. This requires unsafe-fp-math.
However, that legalization assumed that the second step, producing
a pseudo-softened f16, had type i16. That's not true on targets
with illegal i16, such as ARM.
Use the initial f64->f16 result type instead.
llvm-svn: 257794
|
|
|
|
|
|
|
|
|
|
| |
Soon it will be responsible for more than line tables.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D16199
llvm-svn: 257792
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: The dbg.declare -> dbg.value conversion did not check which operand of
the store instruction the alloca was passed to. As a result code that stored the
address of an alloca, rather than storing to the alloca, would still trigger
the conversion routine, leading to the insertion of an incorrect dbg.value
intrinsic.
Reviewers: aprantl
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16169
llvm-svn: 257787
|
|
|
|
|
|
|
|
|
|
|
| |
Coverage mapping data is not referenced by runtime, and they won't be dumped
into profile data. There is no need to allocate memory for covmap sections.
A good side effect of this change is that the coverage map data won't be mistakenly
garbage collected by the linker (for Gold linker only, BFD linker has an issue where the a bug is filed).
Tested with clang build with instrumentation and -fcoverage-mapping and linker GC. The size of
covmap section is ~17.6M so the text segment size will be reduced by this amount with this change.
llvm-svn: 257781
|
|
|
|
|
|
|
|
| |
platforms."
This reverts commit r257719, due to PR26144.
llvm-svn: 257775
|
|
|
|
|
|
| |
This reverts commit r257769. Backing this out because of stage2 failures.
llvm-svn: 257773
|
|
|
|
| |
llvm-svn: 257771
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some patterns of select+compare allow us to know exactly the value of the uppermost bits in the select result. For example:
%b = icmp ugt i32 %a, 5
%c = select i1 %b, i32 2, i32 %a
Here we know that %c is bounded by 5, and therefore KnownZero = ~APInt(5).getActiveBits() = ~7.
There are several such patterns, and this patch attempts to understand a reasonable subset of them - namely when the base values are the same (as above), and when they are related by a simple (add nsw), for example (add nsw %a, 4) and %a.
llvm-svn: 257769
|
|
|
|
| |
llvm-svn: 257768
|
|
|
|
|
|
| |
Loop trip counts can often be resolved during LTO. We should obviously be unrolling small loops once those trip counts have been resolved, but we weren't.
llvm-svn: 257767
|
|
|
|
|
|
| |
No functional change intended.
llvm-svn: 257766
|
|
|
|
|
|
| |
This reverts commit fdb838f3f8a8b6896bbbd5285555874eb3b748eb.
llvm-svn: 257751
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Since globals may escape as function arguments (even when they have been
found to be non-escaping, because of optimizations such as memcpyoptimizer
that replaces stores with memcpy), all arguments to a function are checked
during query to make sure they are identifiable. At that time, also ensure
we return a conservative result only if the arguments don't alias to our global.
Reviewers: hfinkel, jmolloy
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16140
llvm-svn: 257750
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D16142
llvm-svn: 257749
|
|
|
|
| |
llvm-svn: 257748
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The overloads of CallInst::Create and InvokeInst::Create that are used to
adjust operand bundles purport to create a new instruction "identical in
every way except [for] the operand bundles", so copy the DebugLoc along
with everything else.
Reviewers: sanjoy, majnemer
Subscribers: majnemer, dblaikie, llvm-commits
Differential Revision: http://reviews.llvm.org/D16157
llvm-svn: 257745
|
|
|
|
| |
llvm-svn: 257744
|