When the Constant Hoisting pass moves expensive constants into a
common block, it would assign a debug location equal to the last use
of that constant. While this is certainly intuitive, it places the
constant in an out-of-order location, according to the debug location
information. This produces out-of-order stepping when debugging
programs affected by this pass.
This patch creates in-order stepping behavior by merging the debug
locations for hoisted constants, and the new insertion point.
Patch by Matthew Voss!
Differential Revision: https://reviews.llvm.org/D38088
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317827 91177308-0d34-0410-b5e6-96231b3b80d8
Whenever LLVM_ENABLE_ABI_BREAKING_CHECKS is enabled, which
is usually the case for example when asserts are enabled,
Error's destructor does some additional checking to make sure
that that it does not represent an error condition and that it
was checked.
However, this is -- by definition -- not the likely codepath.
Some profiling shows that at least with some compilers, simply
calling assertIsChecked -- in a release build with full
optimizations -- can account for up to 15% of the entire
runtime of the program, even though this function should almost
literally be a no-op.
The problem is that the assertIsChecked function can be considered
too big to inline depending on the compiler's inliner. Since it's
unlikely to ever need to failure path though, we can move it out
of line and force it to not be inlined, so that the fast path
can be inlined.
In my test (using lld to link clang with CMAKE_BUILD_TYPE=Release
and LLVM_ENABLE_ASSERTIONS=ON), this reduces link time from 27
seconds to 23.5 seconds, which is a solid 15% gain.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317824 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The analysis of the store sequence goes in straight order - from the
first store to the last. Bu the best opportunity for vectorization will
happen if we're going to use reverse order - from last store to the
first. It may be best because usually users have some initialization
part + further processing and this first initialization may confuse
SLP vectorizer.
Reviewers: RKSimon, hfinkel, mkuper, spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39606
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317821 91177308-0d34-0410-b5e6-96231b3b80d8
The toxic stew of created values named 'tmp' and tests that already have
values named 'tmp' and CHECK lines looking for values named 'tmp' causes
bad things to happen in our test line auto-generation scripts because it
wants to use 'TMP' as a prefix for unnamed values. Use less 'tmp' to
avoid that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317818 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This fixes failure in CodeGen/AArch64/global-merge-group-by-use.ll uncovered by D39245.
Reviewers: ab, asl
Reviewed By: ab
Subscribers: aemerson, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D39635
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317817 91177308-0d34-0410-b5e6-96231b3b80d8
The reassociate pass generates named values such as "%tmp2" which trips up the script's regex's
because the script uses a 'TMP' prefix for unnamed values (%2).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317810 91177308-0d34-0410-b5e6-96231b3b80d8
We don't really need any special handling of "offsettable"
memory addresses, but since some existing code uses inline
asm statements with the "o" constraint, add support for this
constraint for compatibility purposes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317807 91177308-0d34-0410-b5e6-96231b3b80d8
Correct the definition of 'j' as being unavailable for microMIPS32R6 and
provide the 'b' assembly idiom for codegen purposes for microMIPS32r3.
Provide the necessary 'br' pattern for microMIPS32R6 as it now longer
incorrectly uses the 'j' instruction.
Reviewers: atanasyan
Differential Revision: https://reviews.llvm.org/D39741
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317801 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change allows yaml input to control the order of implicitly added sections
(`.symtab`, `.strtab`, `.shstrtab`). The order is controlled by adding a
placeholder section of the given name to the Sections field.
This change is to support changes in D39582, where it is desirable to control
the location of the `.dynsym` section.
This reapplied version fixes:
1. use of a function call within an assert
2. failing lld test which has an unnamed section
3. incorrect section count when given an unnamed section
Additionally, one more test to cover the unnamed section failure.
Reviewers: compnerd, jakehehrlich
Reviewed By: jakehehrlich
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39749
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317789 91177308-0d34-0410-b5e6-96231b3b80d8
No existing processor has both so it doesn't really matter what we do here. But we were previously just relying on pattern order which gave FMA4 priority.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317775 91177308-0d34-0410-b5e6-96231b3b80d8
We must patch all existing incoming values of Phi node,
otherwise it is possible that we can see poison
where program does not expect to see it.
This is the similar what GVN does.
The added test test/Transforms/GVN/PRE/pre-jt-add.ll shows an
example of wrong optimization done by jump threading due to
GVN PRE did not patch existing incoming value.
Reviewers: mkazantsev, wmi, dberlin, davide
Reviewed By: dberlin
Subscribers: efriedma, llvm-commits
Differential Revision: https://reviews.llvm.org/D39637
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317768 91177308-0d34-0410-b5e6-96231b3b80d8
I think we need to use different builtins for the FMA4 instructions since those instructions zero the upper bits and FMA3 instructions pass the bits through.
So this moves the existing builtins to be the FMA3 versions. New versions will be added for FMA4.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317765 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes an issue where llvm-cov prints an empty line, thinking it
needs to display region markers, when it actually doesn't.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317762 91177308-0d34-0410-b5e6-96231b3b80d8
We've worked around bugs in the frontend by ignoring the count from
wrapped segments when a line has at least one region entry segment.
Those frontend bugs are now fixed, so it's time to regenerate the
checked-in covmapping files and remove the workaround.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317761 91177308-0d34-0410-b5e6-96231b3b80d8
r317453 added new ISD nodes without rounding modes that were added to an existing if/else chain. But all the previous nodes handled there included a rounding mode. The final code after this if/else chain expected an extra operand that isn't present for the new nodes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317748 91177308-0d34-0410-b5e6-96231b3b80d8
Adds the blacklist behaviour to llvm-cfi-verify. Now will calculate which lines caused expected failures in the blacklist and reports the number of affected indirect CF instructions for each blacklist entry.
Also moved DWARF checking after instruction analysis to improve performance significantly - unrolling the inlining stack is expensive.
Reviewers: vlad.tsyrklevich
Subscribers: aprantl, pcc, kcc, llvm-commits
Differential Revision: https://reviews.llvm.org/D39750
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317743 91177308-0d34-0410-b5e6-96231b3b80d8
InMemoryBuffer and OnDiskBuffer classes have both factory methods and
public constructors, and that looks a bit odd. This patch makes factory
methods non-member function to fix it.
Differential Revision: https://reviews.llvm.org/D39693
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317739 91177308-0d34-0410-b5e6-96231b3b80d8
The classof implementation in MaskedGatherScatterSDNode doesn't consider X86MaskedGatherSDNode so its misleading.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317733 91177308-0d34-0410-b5e6-96231b3b80d8
