pass manager passes' `run` methods.
This removes a bunch of SFINAE goop from the pass manager and just
requires pass authors to accept `AnalysisManager<IRUnitT> &` as a dead
argument. This is a small price to pay for the simplicity of the system
as a whole, despite the noise that changing it causes at this stage.
This will also helpfull allow us to make the signature of the run
methods much more flexible for different kinds af passes to support
things like intelligently updating the pass's progression over IR units.
While this touches many, many, files, the changes are really boring.
Mostly made with the help of my trusty perl one liners.
Thanks to Sean and Hal for bouncing ideas for this with me in IRC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272978 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This reverts the changes to Globals.cpp and IRMover.cpp in
"[IR] Copy comdats in GlobalObject::copyAttributesFrom" (D20631,
rL270743).
The DeadArgElim test is left unchanged, and we change DAE to explicitly
copy comdats.
The reverted change breaks copyAttributesFrom when the destination lives
in a different module from the source. The decision in D21255 was to
revert this patch and handle comdat copying separately from
copyAttributesFrom.
Reviewers: majnemer, rnk
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D21403
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272855 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: The current naming not only doesn't convey the meaning of what this does, but worse, it convey the wrong meaning. This was a major source of confusion understanding the code, so I'm applying the boy scout rule here and making it better after I leave.
Reviewers: void, bkramer, whitequark
Differential Revision: http://reviews.llvm.org/D21264
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272725 91177308-0d34-0410-b5e6-96231b3b80d8
If a local_unnamed_addr attribute is attached to a global, the address
is known to be insignificant within the module. It is distinct from the
existing unnamed_addr attribute in that it only describes a local property
of the module rather than a global property of the symbol.
This attribute is intended to be used by the code generator and LTO to allow
the linker to decide whether the global needs to be in the symbol table. It is
possible to exclude a global from the symbol table if three things are true:
- This attribute is present on every instance of the global (which means that
the normal rule that the global must have a unique address can be broken without
being observable by the program by performing comparisons against the global's
address)
- The global has linkonce_odr linkage (which means that each linkage unit must have
its own copy of the global if it requires one, and the copy in each linkage unit
must be the same)
- It is a constant or a function (which means that the program cannot observe that
the unique-address rule has been broken by writing to the global)
Although this attribute could in principle be computed from the module
contents, LTO clients (i.e. linkers) will normally need to be able to compute
this property as part of symbol resolution, and it would be inefficient to
materialize every module just to compute it.
See:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.htmlhttp://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html
for earlier discussion.
Part of the fix for PR27553.
Differential Revision: http://reviews.llvm.org/D20348
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272709 91177308-0d34-0410-b5e6-96231b3b80d8
td_type is std::pair<std::string, std::string>, but the map returns
elements of std::pair<const std::string, std::string>. In well-designed
languages like C++ that yields an implicit copy perfectly hidden by
constref's lifetime extension. Just use auto, the typedef obscured the
real type anyways.
Found with a little help from clang-tidy's
performance-implicit-cast-in-loop.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272519 91177308-0d34-0410-b5e6-96231b3b80d8
Auto-upgrade to generic shuffles like sse/avx2 implementations now that we can lower to VPSLLDQ/VPSRLDQ
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272308 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Now DISubroutineType has a 'cc' field which should be a DW_CC_ enum. If
it is present and non-zero, the backend will emit it as a
DW_AT_calling_convention attribute. On the CodeView side, we translate
it to the appropriate enum for the LF_PROCEDURE record.
I added a new LLVM vendor specific enum to the list of DWARF calling
conventions. DWARF does not appear to attempt to standardize these, so I
assume it's OK to do this until we coordinate with GCC on how to emit
vectorcall convention functions.
Reviewers: dexonsmith, majnemer, aaboud, amccarth
Subscribers: mehdi_amini, llvm-commits
Differential Revision: http://reviews.llvm.org/D21114
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272197 91177308-0d34-0410-b5e6-96231b3b80d8
As suggested by clang-tidy's performance-unnecessary-copy-initialization.
This can easily hit lifetime issues, so I audited every change and ran the
tests under asan, which came back clean.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272126 91177308-0d34-0410-b5e6-96231b3b80d8
Arrange to call verify(Function &) on each function, followed by
verify(Module &), whether the verifier is being used from the pass or
from verifyModule(). As a side effect, this fixes an issue that caused
us not to call verify(Function &) on unmaterialized functions from
verifyModule().
Differential Revision: http://reviews.llvm.org/D21042
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271956 91177308-0d34-0410-b5e6-96231b3b80d8
Remove previously unreachable code that verifies that a function definition has
an entry block. By definition, a function definition has at least one block.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271948 91177308-0d34-0410-b5e6-96231b3b80d8
This patch begins adding support for lowering to the XOP VPERMIL2PD/VPERMIL2PS shuffle instructions - adding the X86ISD::VPERMIL2 opcode and cleaning up the usage.
The internal llvm intrinsics were assuming the shuffle mask operand was the same type as the float/double input operands (I guess to simplify the intrinsic definitions in X86InstrXOP.td to a single value type). These needed changing to integer types (matching the clang builtin and the AMD intrinsics definitions), an auto upgrade path is added to convert old calls.
Mask decoding/target shuffle support will be added in future patches.
Differential Revision: http://reviews.llvm.org/D20049
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271633 91177308-0d34-0410-b5e6-96231b3b80d8
This patch removes the llvm intrinsics (V)CVTTPS2DQ and VCVTTPD2DQ truncation (round to zero) conversions and auto-upgrades to FP_TO_SINT calls instead.
Note: I looked at updating CVTTPD2DQ as well but this still requires a lot more work to correctly lower.
Differential Revision: http://reviews.llvm.org/D20860
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271510 91177308-0d34-0410-b5e6-96231b3b80d8
... and merge into `Value::getPointerDereferenceableBytes`. This was
suggested by Artur Pilipenko in D20764 -- since we no longer allow loads
of unsized types, there is no need anymore to have this special logic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271455 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
It isn't clear what is the operational meaning of loading or storing an
unsized types, since it cannot be lowered into something meaningful.
Since there does not seem to be any practical need for it either, make
such loads and stores illegal IR.
Reviewers: majnemer, chandlerc
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D20846
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271402 91177308-0d34-0410-b5e6-96231b3b80d8
Looks like something isn't quite right still. Also forgot to move the test cases to an autoupgrade test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271363 91177308-0d34-0410-b5e6-96231b3b80d8
This will be necessary to allow the global merge pass to attach
multiple debug info metadata nodes to global variables once we reverse
the edge from DIGlobalVariable to GlobalVariable.
Differential Revision: http://reviews.llvm.org/D20414
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271358 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds an IR, assembly and bitcode representation for metadata
attachments for globals. Future patches will port existing features to use
these new attachments.
Differential Revision: http://reviews.llvm.org/D20074
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271348 91177308-0d34-0410-b5e6-96231b3b80d8
This will be used in a follow up commit to simplify code in clang that creates a ConstantDataVector and calls the other form.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271164 91177308-0d34-0410-b5e6-96231b3b80d8
This patch removes the llvm intrinsics VPMOVSX and (V)PMOVZX sign/zero extension intrinsics and auto-upgrades to SEXT/ZEXT calls instead. We already did this for SSE41 PMOVSX sometime ago so much of that implementation can be reused.
Reapplied now that the the companion patch (D20684) removes/auto-upgrade the clang intrinsics has been committed.
Differential Revision: http://reviews.llvm.org/D20686
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271131 91177308-0d34-0410-b5e6-96231b3b80d8
r231483 taught ConstantRange::multiply to be clever about signed vs unsigned ranges. For example, an unsigned range could be full-set while the signed range is more specific than that.
In looking at the allocations trace for LTO'ing verify-uselistorder (see r236629 for details), millions of allocations are from APInt, many of which come from ConstantRange's.
This change tries to avoid some (3.2 million) allocations by returning the unsigned range if its suitable. The checks here are that it should not be a wrapping range, and should be positive. That should be enough to check for ranges such as [1, 10) which the signed range will be equal to, if we were to calculate it.
Differential Revision: http://reviews.llvm.org/D20723
Reviewed by James Molloy
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271020 91177308-0d34-0410-b5e6-96231b3b80d8
This patch removes the llvm intrinsics VPMOVSX and (V)PMOVZX sign/zero extension intrinsics and auto-upgrades to SEXT/ZEXT calls instead. We already did this for SSE41 PMOVSX sometime ago so much of that implementation can be reused.
A companion patch (D20684) removes/auto-upgrade the clang intrinsics.
Differential Revision: http://reviews.llvm.org/D20686
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270973 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
If an index for a vector or array type is out-of-range GEP constant
folding tries to factor it into preceding dimensions. The code however
does not consider addressing of structure field padding which should not
qualify as out-of-range index.
As demonstrated by the testcase, this can occur if the indexing
performed on a vector type and the preceding index is an array type.
SROA generates GEPs for example involving padding bytes as it slices an
alloca.
My fix disables this folding if the element type is a vector type. I
believe that this is the only way we can end up with padding. (We have
no access to DataLayout so I am not sure if there is actual robust way
of actually checking the presence of padding.)
Reviewers: majnemer
Subscribers: llvm-commits, Gerolf
Differential Revision: http://reviews.llvm.org/D20663
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270826 91177308-0d34-0410-b5e6-96231b3b80d8
When we have "Image Info Version" module flag but don't have "Class Properties"
module flag, set "Class Properties" module flag to 0, so we can correctly emit
errors when one module has the flag set and another module does not.
rdar://26469641
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270791 91177308-0d34-0410-b5e6-96231b3b80d8
Since r268966 the modern Verifier pass defaults to stripping invalid debug info
in nonasserts builds. This patch ports this behavior back to the legacy
Verifier pass as well. The primary motivation is that the clang frontend
accepts bitcode files as input but is still using the legacy pass pipeline.
Background: The problem I'm trying to solve with this sequence of patches is
that historically we've done a really bad job at verifying debug info. We want
to be able to make the verifier stricter without having to worry about breaking
bitcode compatibility with existing producers. For example, we don't necessarily
want IR produced by an older version of clang to be rejected by an LTO link just
because of malformed debug info, and rather provide an option to strip it. Note
that merely outdated (but well-formed) debug info would continue to be
auto-upgraded in this scenario.
http://reviews.llvm.org/D20629
<rdar://problem/26448800>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270768 91177308-0d34-0410-b5e6-96231b3b80d8
This is probably correct for all uses except cross-module IR linking,
where we need to move the comdat from the source module to the
destination module.
Fixes PR27870.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D20631
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270743 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This needs to get in before anything is released concerning attribute. If the old name gets in the wild, then we are stuck with it forever. Putting it in its own diff should getting that part at least in fast.
Reviewers: Wallbraker, whitequark, joker.eph, echristo, rafael, jyknight
Subscribers: llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D20417
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270452 91177308-0d34-0410-b5e6-96231b3b80d8
This splits ProfileSummary into two classes: a ProfileSummary class that has methods to convert from/to metadata and a ProfileSummaryBuilder class that computes the profiles summary which is in ProfileData.
Differential Revision: http://reviews.llvm.org/D20314
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270136 91177308-0d34-0410-b5e6-96231b3b80d8
Currently only its unit test uses it, but this will be used in a later
change to simplify some logic in the GuardWidening pass.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270018 91177308-0d34-0410-b5e6-96231b3b80d8
Without a diagnostic handler installed, llc's behaviour is to exit on the first
error that it encounters. This is very different from the behaviour of clang
and other front ends, which try to gather as many errors as possible before
exiting.
This commit adds a diagnostic handler to llc, allowing it to find and report
more than one error. The old behaviour is preserved under a flag (-exit-on-error).
Some of the tests fail with the new diagnostic handler, so they have to use the
new flag in order to run under the previous behaviour. Some of these are known
bugs, others need further investigation. Ideally, we should fix the tests and
remove the flag at some point in the future.
Reapplied after fixing the LLDB build that was broken due to the new
DiagnosticSeverity in LLVMContext.h, and fixed an UB in the new change.
Patch by Diana Picus.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269655 91177308-0d34-0410-b5e6-96231b3b80d8
Without a diagnostic handler installed, llc's behaviour is to exit on the first
error that it encounters. This is very different from the behaviour of clang
and other front ends, which try to gather as many errors as possible before
exiting.
This commit adds a diagnostic handler to llc, allowing it to find and report
more than one error. The old behaviour is preserved under a flag (-exit-on-error).
Some of the tests fail with the new diagnostic handler, so they have to use the
new flag in order to run under the previous behaviour. Some of these are known
bugs, others need further investigation. Ideally, we should fix the tests and
remove the flag at some point in the future.
Reapplied after fixing the LLDB build that was broken due to the new
DiagnosticSeverity in LLVMContext.h.
Patch by Diana Picus.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269563 91177308-0d34-0410-b5e6-96231b3b80d8
Suggested by Adrian. This is NFC right now but is more clean and
robust against future potential new debug info intrinsics.
From: mehdi_amini <mehdi_amini@91177308-0d34-0410-b5e6-96231b3b80d8>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269540 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r269537, was not ready to be commited and went through by mistake
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269539 91177308-0d34-0410-b5e6-96231b3b80d8
Suggested by Adrian. This is NFC right now but is more clean and
robust against future potential new debug info intrinsics.
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269537 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r269428, as it breaks the LLDB build. We need to
understand how to change LLDB in the same way as LLC before landing this
again.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269432 91177308-0d34-0410-b5e6-96231b3b80d8
Without a diagnostic handler installed, llc's behaviour is to exit on the first
error that it encounters. This is very different from the behaviour of clang
and other front ends, which try to gather as many errors as possible before
exiting.
This commit adds a diagnostic handler to llc, allowing it to find and report
more than one error. The old behaviour is preserved under a flag (-exit-on-error).
Some of the tests fail with the new diagnostic handler, so they have to use the
new flag in order to run under the previous behaviour. Some of these are known
bugs, others need further investigation. Ideally, we should fix the tests and
remove the flag at some point in the future.
Patch by Diana Picus.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269428 91177308-0d34-0410-b5e6-96231b3b80d8
This new verifier rule lets us unambigously pick a calling convention
when creating a new declaration for
`@llvm.experimental.deoptimize.<ty>`. It is also congruent with our
lowering strategy -- since all calls to `@llvm.experimental.deoptimize`
are lowered to calls to `__llvm_deoptimize`, it is reasonable to enforce
a unique calling convention.
Some of the tests that were breaking this verifier rule have had to be
split up into different .ll files.
The inliner was violating this rule as well, and has been fixed to avoid
producing invalid IR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269261 91177308-0d34-0410-b5e6-96231b3b80d8
DbgInfoIntrinsic::StripCast() is dead since r79977
The only function that creates Comdat objects seems to be in Module, and always creates them using the default constructor.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269204 91177308-0d34-0410-b5e6-96231b3b80d8
allow the transformation to strip invalid debug info.
This patch separates the Verifier into an analysis and a transformation
pass, with the transformation pass optionally stripping malformed
debug info.
The problem I'm trying to solve with this sequence of patches is that
historically we've done a really bad job at verifying debug info. We want
to be able to make the verifier stricter without having to worry about
breaking bitcode compatibility with existing producers. For example, we
don't necessarily want IR produced by an older version of clang to be
rejected by an LTO link just because of malformed debug info, and rather
provide an option to strip it. Note that merely outdated (but well-formed)
debug info would continue to be auto-upgraded in this scenario.
http://reviews.llvm.org/D19988
rdar://problem/25818489
This reapplies r268937 without modifications.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268966 91177308-0d34-0410-b5e6-96231b3b80d8
This patch introduces a new option -lto-strip-invalid-debug-info, which
drops malformed debug info from the input.
The problem I'm trying to solve with this sequence of patches is that
historically we've done a really bad job at verifying debug info. We want
to be able to make the verifier stricter without having to worry about
breaking bitcode compatibility with existing producers. For example, we
don't necessarily want IR produced by an older version of clang to be
rejected by an LTO link just because of malformed debug info, and rather
provide an option to strip it. Note that merely outdated (but well-formed)
debug info would continue to be auto-upgraded in this scenario.
rdar://problem/25818489
http://reviews.llvm.org/D19987
This reapplies 268936 with a test case fix for Linux (-exported-symbol foo)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268965 91177308-0d34-0410-b5e6-96231b3b80d8
allow the transformation to strip invalid debug info.
This patch separates the Verifier into an analysis and a transformation
pass, with the transformation pass optionally stripping malformed
debug info.
The problem I'm trying to solve with this sequence of patches is that
historically we've done a really bad job at verifying debug info. We want
to be able to make the verifier stricter without having to worry about
breaking bitcode compatibility with existing producers. For example, we
don't necessarily want IR produced by an older version of clang to be
rejected by an LTO link just because of malformed debug info, and rather
provide an option to strip it. Note that merely outdated (but well-formed)
debug info would continue to be auto-upgraded in this scenario.
http://reviews.llvm.org/D19988
rdar://problem/25818489
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268937 91177308-0d34-0410-b5e6-96231b3b80d8
This patch introduces a new option -lto-strip-invalid-debug-info, which
drops malformed debug info from the input.
The problem I'm trying to solve with this sequence of patches is that
historically we've done a really bad job at verifying debug info. We want
to be able to make the verifier stricter without having to worry about
breaking bitcode compatibility with existing producers. For example, we
don't necessarily want IR produced by an older version of clang to be
rejected by an LTO link just because of malformed debug info, and rather
provide an option to strip it. Note that merely outdated (but well-formed)
debug info would continue to be auto-upgraded in this scenario.
rdar://problem/25818489
http://reviews.llvm.org/D19987
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268936 91177308-0d34-0410-b5e6-96231b3b80d8
This moves the code that handles stripping debug info intrinsic from
StripDebugInfo(Module) to StripDebugInfo(Function). The latter is
already walking every instructions so it makes sense to do it at the
same time.
This makes also stripDebugInfo(Function) as an API more useful: it
is really dropping every debug info in the Function.
Finally the existing code is trigerring an assertion when the Module
is not fully materialized.
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268847 91177308-0d34-0410-b5e6-96231b3b80d8
This moves the code that handles stripping debug info intrinsic from
StripDebugInfo(Module) to StripDebugInfo(Function). The latter is
already walking every instructions so it makes sense to do it at the
same time.
This makes also stripDebugInfo(Function) as an API more useful: it
is really dropping every debug info in the Function.
Finally the existing code is trigerring an assertion when the Module
is not fully materialized.
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268832 91177308-0d34-0410-b5e6-96231b3b80d8
info metadata errors separately. (NFC)
This patch refactors the Verifier so it can diagnose IR validation errors
and debug info metadata errors separately.
The motivation behind this change is that broken (or outdated) debug info
can be "recovered" from by stripping the debug info.
The problem I'm trying to solve with this sequence of patches is that
historically we've done a really bad job at verifying debug info.
We want to be able to make the verifier stricter without having to worry
about breaking bitcode compatibility with existing producers. For example,
we don't necessarily want IR produced by an older version of clang to be
rejected by an LTO link just because of malformed debug info, and rather
provide an option to strip it. Note that merely outdated (but well-formed)
debug info would continue to be auto-upgraded in this scenario.
http://reviews.llvm.org/D19986
rdar://problem/25818489
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268778 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This will be used for AMDGPU_HSA_KERNEL symbol type in output ELF.
Also, in the future unused non-kernels may be optimized.
For now, also accept SPIR_KERNEL for HCC frontend.
Also, add bitcode compatibility tests for missing calling conventions
except AVR_BUILTIN which doesn't have parse code.
Reviewers: tstellarAMD, arsenm
Subscribers: arsenm, joker.eph, llvm-commits
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268717 91177308-0d34-0410-b5e6-96231b3b80d8
This reapplies commit r268521, that was reverted in r268530 due to a test failure in select-implied.ll
Modified the test case to reflect the new change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268557 91177308-0d34-0410-b5e6-96231b3b80d8
ConstantFold has logic to take icmp (bitcast x to y), null and strip the
bitcast. This makes sense in general, but not if x has floating-point type. In
this case, we'd need a fcmp, not an icmp, and the code will assert. We normally
don't see this situation because we constant fold fp -> int bitcasts, however,
we'll see it for bitcasts of ppc_fp128 -> i128. This is because that bitcast is
Endian-dependent, and as a result, we don't simplify it in ConstantFold (we
could, but no one has yet added the necessary logic). Regardless, ConstantFold
should not depend on that canonicalization for correctness.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268534 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r268254.
This change causes assertion failures while building Chromium. Reduced
test case coming soon.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268288 91177308-0d34-0410-b5e6-96231b3b80d8
Make it possible that TryToSimplifyUncondBranchFromEmptyBlock merges empty
basic block including lifetime intrinsics as well as phi nodes and
unconditional branch into its successor or predecessor(s).
If successor of empty block has single predecessor, all contents including
lifetime intrinsics are sinked into the successor. Otherwise, they are
hoisted into its predecessor(s) and then merged into the predecessor(s).
Patch by Josh Yoon <josh.yoon@samsung.com>!
Differential Revision: http://reviews.llvm.org/D19257
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268254 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Historically, we had a switch in the Makefiles for turning on "expensive
checks". This has never been ported to the cmake build, but the
(dead-ish) code is still around.
This will also make it easier to turn it on in buildbots.
Reviewers: chandlerc
Subscribers: jyknight, mzolotukhin, RKSimon, gberry, llvm-commits
Differential Revision: http://reviews.llvm.org/D19723
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268050 91177308-0d34-0410-b5e6-96231b3b80d8
We neglected to transfer operand bundles for some transforms. These
were found via inspection, I'll try to come up with some test cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268011 91177308-0d34-0410-b5e6-96231b3b80d8
Extract a part of isDereferenceableAndAlignedPointer functionality to Value::getPointerDerferecnceableBytes. Currently it's a NFC, but in future I'm going to accumulate all the logic about value dereferenceability in this function similarly to Value::getPointerAlignment function (D16144).
Reviewed By: reames
Differential Revision: http://reviews.llvm.org/D17572
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267708 91177308-0d34-0410-b5e6-96231b3b80d8
This is part of solving PR27344:
https://llvm.org/bugs/show_bug.cgi?id=27344
CGP should undo the SimplifyCFG transform for the same reason that earlier patches have used this
same mechanism: it's possible that passes between SimplifyCFG and CGP may be able to optimize the
IR further with a select in place.
For the TLI hook default, >99% taken or not taken is chosen as the default threshold for a highly
predictable branch. Even the most limited HW branch predictors will be correct on this branch almost
all the time, so even a massive mispredict penalty perf loss would be overcome by the win from all
the times the branch was predicted correctly.
As a follow-up, we could make the default target hook less conservative by using the SchedMachineModel's
MispredictPenalty. Or we could just let targets override the default by implementing the hook with that
and other target-specific options. Note that trying to statically determine mispredict rates for
close-to-balanced profile weight data is generally impossible if the HW is sufficiently advanced. Ie,
50/50 taken/not-taken might still be 100% predictable.
Finally, note that this patch as-is will not solve PR27344 because the current __builtin_unpredictable()
branch weight default values are 4 and 64. A proposal to change that is in D19435.
Differential Revision: http://reviews.llvm.org/D19488
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267572 91177308-0d34-0410-b5e6-96231b3b80d8
While we're here, fix the comment and variable names to make it
clear that these are raw weights, not percentages.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267491 91177308-0d34-0410-b5e6-96231b3b80d8
Add a typedef for the std::map<GlobalValue::GUID, GlobalValueSummary *>
map that is passed around to identify summaries for values defined in a
particular module. This shortens up declarations in a variety of places.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267471 91177308-0d34-0410-b5e6-96231b3b80d8
in a debug-info-bearing function has a debug location attached to it. Failure to
do so causes an "!dbg attachment points at wrong subprogram for function"
assertion failure when the inliner sets up inline scope info.
rdar://problem/25878916
This reaplies r267320 without changes after fixing an issue in the OpenMP IR
generator in clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267370 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Remove the GlobalValueInfo and change the ModuleSummaryIndex to directly
reference summary objects. The info structure was there to support lazy
parsing of the combined index summary objects, which is no longer
needed and not supported.
Reviewers: joker.eph
Subscribers: joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D19462
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267344 91177308-0d34-0410-b5e6-96231b3b80d8
in a debug-info-bearing function has a debug location attached to it. Failure to
do so causes an "!dbg attachment points at wrong subprogram for function"
assertion failure when the inliner sets up inline scope info.
rdar://problem/25878916
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267320 91177308-0d34-0410-b5e6-96231b3b80d8
A long overdue change to make DIGlobalVariable distinct. Much like
DISubprogram definitions (changed in r246098), it isn't logical to
unique DIGlobalVariable definitions from two different compile units.
(Longer-term, we should also find a way to reverse the link between
GlobalVariable and DIGlobalVariable, and between DIGlobalVariable and
DICompileUnit, so that debug info to do with optimized-out globals
disappears. Admittedly it's harder than with Function/DISubprogram,
since global variables may be constant-folded and the debug info should
still describe that somehow.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267301 91177308-0d34-0410-b5e6-96231b3b80d8
Eliminate DITypeIdentifierMap and make DITypeRef a thin wrapper around
DIType*. It is no longer legal to refer to a DICompositeType by its
'identifier:', and DIBuilder no longer retains all types with an
'identifier:' automatically.
Aside from the bitcode upgrade, this is mainly removing logic to resolve
an MDString-based reference to an actualy DIType. The commits leading
up to this have made the implicit type map in DICompileUnit's
'retainedTypes:' field superfluous.
This does not remove DITypeRef, DIScopeRef, DINodeRef, and
DITypeRefArray, or stop using them in DI-related metadata. Although as
of this commit they aren't serving a useful purpose, there are patchces
under review to reuse them for CodeView support.
The tests in LLVM were updated with deref-typerefs.sh, which is attached
to the thread "[RFC] Lazy-loading of debug info metadata":
http://lists.llvm.org/pipermail/llvm-dev/2016-April/098318.html
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267296 91177308-0d34-0410-b5e6-96231b3b80d8
Each reference to an unresolved MDNode is expensive, since the RAUW
support in MDNode uses a separate allocation and side map. Since
a distinct MDNode doesn't require its operands on creation (unlike
uniuqed nodes, there's no need to check for structural equivalence),
use nullptr for any of its unresolved operands. Besides reducing the
burden on MDNode maps, this can avoid allocating temporary MDNodes in
the first place.
We need some way to track operands. Invent DistinctMDOperandPlaceholder
for this purpose, which is a Metadata subclass that holds an ID and
points at its single user. DistinctMDOperandPlaceholder::replaceUseWith
is just like RAUW, but its name highlights that there is only ever
exactly one use.
There is no support for moving (or, obviously, copying) these. Move
support would be possible but expensive; leaving it unimplemented
prevents user error. In the BitcodeReader I originally considered
allocating on a BumpPtrAllocator and keeping a vector of pointers to
them, and then I realized that std::deque implements exactly this.
A couple of obvious follow-ups:
- Change ValueEnumerator to emit distinct nodes first to take more
advantage of this optimization. (How convenient... I think I might
have a couple of patches for this.)
- Change DIBuilder and its consumers (like CGDebugInfo in clang) to
use something like this when constructing debug info in the first
place.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267270 91177308-0d34-0410-b5e6-96231b3b80d8
The only functionality change was removing an error check from the
BitcodeReader (and an assertion from DILocation::getImpl) that is
already caught by Verifier::visitDILocation. The Verifier is a better
place for this anyway, and being inconsistent with other subclasses of
MDNode isn't serving anyone.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267267 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: [u|s]gt and [u|s]lt imply [u|s]ge and [u|s]le are true, respectively.
I've simplified the existing tests and added additional tests to cover the new
cases mentioned above. I've also added tests for all the cases where the
first compare doesn't imply anything about the second compare.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267171 91177308-0d34-0410-b5e6-96231b3b80d8
We assumed that flags were only present on binary operators. This is
not true, they may also be present on calls and fcmps.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267113 91177308-0d34-0410-b5e6-96231b3b80d8
EarlyCSE had inconsistent behavior with regards to flag'd instructions:
- In some cases, it would pessimize if the available instruction had
different flags by not performing CSE.
- In other cases, it would miscompile if it replaced an instruction
which had no flags with an instruction which has flags.
Fix this by being more consistent with our flag handling by utilizing
andIRFlags.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267111 91177308-0d34-0410-b5e6-96231b3b80d8
This patch implements a optimization bisect feature, which will allow optimizations to be selectively disabled at compile time in order to track down test failures that are caused by incorrect optimizations.
The bisection is enabled using a new command line option (-opt-bisect-limit). Individual passes that may be skipped call the OptBisect object (via an LLVMContext) to see if they should be skipped based on the bisect limit. A finer level of control (disabling individual transformations) can be managed through an addition OptBisect method, but this is not yet used.
The skip checking in this implementation is based on (and replaces) the skipOptnoneFunction check. Where that check was being called, a new call has been inserted in its place which checks the bisect limit and the optnone attribute. A new function call has been added for module and SCC passes that behaves in a similar way.
Differential Revision: http://reviews.llvm.org/D19172
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@267022 91177308-0d34-0410-b5e6-96231b3b80d8
