Causes unexpected memory issue with New PM this time.
The new PM invalidates BPI but not BFI, leaving the
reference to BPI from BFI invalid.
Abandon this patch. There is a more general solution
which also handles runtime infinite loop (but not statically).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320180 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
llvm-objdump's Mach-O parser was updated in r306037 to display external
relocations for MH_KEXT_BUNDLE file types. This change extends the Macho-O
parser to display local relocations for MH_PRELOAD files. When used with
the -macho option relocations will be displayed in a historical format.
rdar://35778019
Reviewers: enderby
Reviewed By: enderby
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40867
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320166 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Make enum ModRefInfo an enum class. Changes to ModRefInfo values should
be done using inline wrappers.
This should prevent future bit-wise opearations from being added, which can be more error-prone.
Reviewers: sanjoy, dberlin, hfinkel, george.burgess.iv
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40933
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320107 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This did not work because the ExpectedHolder was trying to hold the
value in an Optional<T*>. Instead of trying to mimic the behavior of
Expected and try to make ExpectedHolder work with references and
non-references, I simply store the reference to the Expected object in
the holder.
I also add a bunch of tests for these matchers, which have helped me
flesh out some problems in my initial implementation of this patch, and
uncovered the fact that we are not consistent in quoting our values in
the matcher output (which I also fix).
Reviewers: zturner, chandlerc
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D40904
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320025 91177308-0d34-0410-b5e6-96231b3b80d8
A number of architectures re-use the same register names (e.g. for both 32-bit
FPRs and 64-bit FPRs). They are currently unable to use the tablegen'erated
MatchRegisterName and MatchRegisterAltName, as tablegen (when built with
asserts enabled) will fail.
When the AllowDuplicateRegisterNames in AsmParser is set, duplicated register
names will be tolerated. A backend can then coerce registers to the desired
register class by (for instance) implementing validateTargetOperandClass.
At least the in-tree Sparc backend could benefit from this, as does RISC-V
(single and double precision floating point registers).
Differential Revision: https://reviews.llvm.org/D39845
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@320018 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch adds MachineCombiner patterns for transforming
(fsub (fmul x y) z) into (fma x y (fneg z)). This has a lower
latency on micro architectures where fneg is cheap.
Patch based on work by George Steed.
Reviewers: rengolin, joelkevinjones, joel_k_jones, evandro, efriedma
Reviewed By: evandro
Subscribers: aemerson, javed.absar, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D40306
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319980 91177308-0d34-0410-b5e6-96231b3b80d8
This patch factors out the main code transformation utilities in the pgo-driven
indirect call promotion pass and places them in Transforms/Utils. The change is
intended to be a non-functional change, letting non-pgo-driven passes share a
common implementation with the existing pgo-driven pass.
The common utilities are used to conditionally promote indirect call sites to
direct call sites. They perform the underlying transformation, and do not
consider profile information. The pgo-specific details (e.g., the computation
of branch weight metadata) have been left in the indirect call promotion pass.
Differential Revision: https://reviews.llvm.org/D40658
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319963 91177308-0d34-0410-b5e6-96231b3b80d8
WASM_STACK_POINTER and the .stack_pointer directive are no longer needed
now that the stack pointer global is an import.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319956 91177308-0d34-0410-b5e6-96231b3b80d8
Tabort (transaction abort) does not load from memory.
mayLoad flag removed from corresponding TABORT machine instruction.
Review: Ulrich Weigand
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319905 91177308-0d34-0410-b5e6-96231b3b80d8
This caused PR35519.
> [memcpyopt] Teach memcpyopt to optimize across basic blocks
>
> This teaches memcpyopt to make a non-local memdep query when a local query
> indicates that the dependency is non-local. This notably allows it to
> eliminate many more llvm.memcpy calls in common Rust code, often by 20-30%.
>
> Fixes PR28958.
>
> Differential Revision: https://reviews.llvm.org/D38374
>
> [memcpyopt] Commit file missed in r319482.
>
> This change was meant to be included with r319482 but was accidentally
> omitted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319873 91177308-0d34-0410-b5e6-96231b3b80d8
comparison of symbol names.
SymbolStringPool is a thread-safe string pool that will be used in upcoming Orc
APIs to facilitate efficient storage and fast comparison of symbol name strings.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319839 91177308-0d34-0410-b5e6-96231b3b80d8
The patch originally broke Chromium (crbug.com/791714) due to its failing to
specify that the new pseudo instructions clobber EFLAGS. This commit fixes
that.
> Summary: This strengthens the guard and matches MSVC.
>
> Reviewers: hans, etienneb
>
> Subscribers: hiraditya, JDevlieghere, vlad.tsyrklevich, llvm-commits
>
> Differential Revision: https://reviews.llvm.org/D40622
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319824 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The aim is to make ModRefInfo checks and changes more intuitive
and less error prone using inline methods that abstract the bit operations.
Ideally ModRefInfo would become an enum class, but that change will require
a wider set of changes into FunctionModRefBehavior.
Reviewers: sanjoy, george.burgess.iv, dberlin, hfinkel
Subscribers: nlopes, llvm-commits
Differential Revision: https://reviews.llvm.org/D40749
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319821 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Found out, at code inspection, that there was a fault in
DAGCombiner::CombineConsecutiveLoads for big-endian targets.
A BUILD_PAIR is always having the least significant bits of
the composite value in element 0. So when we are doing the checks
for consecutive loads, for big endian targets, we should check
if the load to elt 1 is at the lower address and the load
to elt 0 is at the higher address.
Normally this bug only resulted in missed oppurtunities for
doing the load combine. I guess that in some rare situation it
could lead to faulty combines, but I've not seen that happen.
Note that this patch actually will trigger load combine for
some big endian regression tests.
One example is test/CodeGen/PowerPC/anon_aggr.ll where we now get
t76: i64,ch = load<LD8[FixedStack-9]
instead of
t37: i32,ch = load<LD4[FixedStack-10]>
t35: i32,ch = load<LD4[FixedStack-9]>
t41: i64 = build_pair t37, t35
before legalization. Then the legalization will split the LD8
into two loads, so the end result is the same. That should
verify that the transfomation is correct now.
Reviewers: niravd, hfinkel
Reviewed By: niravd
Subscribers: nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D40444
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319771 91177308-0d34-0410-b5e6-96231b3b80d8
This has proven a healthy exercise, as many cases of incorrect instruction
flags were corrected in the process. As part of this, IntrWriteMem was added
to several SystemZ instrinsics.
Furthermore, a bug was exposed in TwoAddress with this change (as incorrect
hasSideEffects flags were removed and instructions could now be sunk), and
the test case for that bugfix (r319646) is included here as
test/CodeGen/SystemZ/twoaddr-sink.ll.
One temporary test regression (one extra copy) which will hopefully go away
in upcoming patches for similar cases:
test/CodeGen/SystemZ/vec-trunc-to-i1.ll
Review: Ulrich Weigand.
https://reviews.llvm.org/D40437
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319756 91177308-0d34-0410-b5e6-96231b3b80d8
MachineRegisterInfo used to allow just one regalloc hint per virtual
register. This patch extends this to a vector of regalloc hints, which is
filled in by common code with sorted copy hints. Such hints will make for
more ID copies that can be removed.
NB! This improvement is currently (and hopefully temporarily) *disabled* by
default, except for SystemZ. The only reason for this is the big impact this
has on tests, which has unfortunately proven unmanageable. It was a long
while since all the tests were updated and just waiting for review (which
didn't happen), but now targets have to enable this themselves
instead. Several targets could get a head-start by downloading the tests
updates from the Phabricator review. Thanks to those who helped, and sorry
you now have to do this step yourselves.
This should be an improvement generally for any target!
The target may still create its own hint, in which case this has highest
priority and is stored first in the vector. If it has target-type, it will
not be recomputed, as per the previous behaviour.
The temporary hook enableMultipleCopyHints() will be removed as soon as all
targets return true.
Review: Quentin Colombet, Ulrich Weigand.
https://reviews.llvm.org/D38128
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319754 91177308-0d34-0410-b5e6-96231b3b80d8
This is for PR35460.
Currently when LLD adds files to TarWriter it may pass the same file
multiple times. For example it happens for clang reproduce file which specifies
archive (.a) files more than once in command line.
Patch makes TarWriter to ignore files with the same path, so it will
add only the first one to archive.
Differential revision: https://reviews.llvm.org/D40606
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319750 91177308-0d34-0410-b5e6-96231b3b80d8
Consistently use the same parameter names as the names of the affected
fields. This avoids some unintuitive abbreviations like `isSS`.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319722 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
While implementing atomicrmw in https://reviews.llvm.org/D40092 I found that
inheritance is unusable for all the Generic Opcodes in GlobalISel. This is
because the whole header is included inside a 'let mayLoad = 0, mayStore = 0 ... in'
block. In TableGen, the order of precedence for field assignments is:
1. Values from classes the record inherits from.
2. Values from 'let Name=Value in { ... }'
3. Values from 'let Name=Value;'
As such the 'let mayLoad = 0, mayStore = 0, ... in' surrounding the
'include "GenericOpcodes.td"' was overriding any values provided via inheritance.
We hadn't noticed this before because we were only using 'let Name=Value;' to
specialize opcodes.
Fix this by moving the default values to the lowest precedence. This is
accomplished by moving the values to a common base class
(StandardPseudoInstruction for most TargetOpcodes, and GenericOpcode for
GlobalISel specific TargetOpcodes)
Reviewers: qcolombet
Reviewed By: qcolombet
Subscribers: llvm-commits, igorb
Differential Revision: https://reviews.llvm.org/D40096
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319701 91177308-0d34-0410-b5e6-96231b3b80d8
This patch splits atomics out of the generic G_LOAD/G_STORE and into their own
G_ATOMIC_LOAD/G_ATOMIC_STORE. This is a pragmatic decision rather than a
necessary one. Atomic load/store has little in implementation in common with
non-atomic load/store. They tend to be handled very differently throughout the
backend. It also has the nice side-effect of slightly improving the common-case
performance at ISel since there's no longer a need for an atomicity check in the
matcher table.
All targets have been updated to remove the atomic load/store check from the
G_LOAD/G_STORE path. AArch64 has also been updated to mark
G_ATOMIC_LOAD/G_ATOMIC_STORE legal.
There is one issue with this patch though which also affects the extending loads
and truncating stores. The rules only match when an appropriate G_ANYEXT is
present in the MIR. For example,
(G_ATOMIC_STORE (G_TRUNC:s16 (G_ANYEXT:s32 (G_ATOMIC_LOAD:s16 X))))
will match but:
(G_ATOMIC_STORE (G_ATOMIC_LOAD:s16 X))
will not. This shouldn't be a problem at the moment, but as we get better at
eliminating extends/truncates we'll likely start failing to match in some
cases. The current plan is to fix this in a patch that changes the
representation of extending-load/truncating-store to allow the MMO to describe
a different type to the operation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319691 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Move splitIndirectCriticalEdges() from CodeGenPrepare to BasicBlockUtils.h so
that it can be called from other places.
Reviewers: davidxl
Reviewed By: davidxl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40750
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319689 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
I don't think rL309080 is the right fix for PR33494 -- caching ExitLimit only
hides the problem[0]. The real issue is that because of how we forget SCEV
expressions ScalarEvolution::getBackedgeTakenInfo, in the test case for PR33494
computing the backedge for any loop invalidates the trip count for every other
loop. This effectively makes the SCEV cache useless.
I've instead made the SCEV expression invalidation in
ScalarEvolution::getBackedgeTakenInfo less aggressive to fix this issue.
[0]: One way to think about this is that rL309080 essentially augmented the
backedge-taken-count cache with another equivalent exit-limit cache. The bug
went away because we were explicitly not clearing the exit-limit cache in
getBackedgeTakenInfo. But instead of doing all of that, we can just avoid
clearing the backedge-taken-count cache.
Reviewers: mkazantsev, mzolotukhin
Subscribers: mcrosier, llvm-commits
Differential Revision: https://reviews.llvm.org/D39361
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319678 91177308-0d34-0410-b5e6-96231b3b80d8
As part of the unification of the debug format and the MIR format, print
MBB references as '%bb.5'.
The MIR printer prints the IR name of a MBB only for block definitions.
* find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g'
* find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g'
* find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g'
* grep -nr 'BB#' and fix
Differential Revision: https://reviews.llvm.org/D40422
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319665 91177308-0d34-0410-b5e6-96231b3b80d8
This is causing a failure in the llvm-clang-x86_64-expensive-checks-win
buildbot, and I can't reproduce it locally, so reverting until I can work out
what is wrong.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319654 91177308-0d34-0410-b5e6-96231b3b80d8
This adds a "invalid operands for instruction" diagnostic for
instructions where there is an instruction encoding with the correct
mnemonic and which is available for this target, but where multiple
operands do not match those which were provided. This makes it clear
that there is some combination of operands that is valid for the current
target, which the default diagnostic of "invalid instruction" does not.
Since this is a very general error, we only emit it if we don't have a
more specific error.
Differential revision: https://reviews.llvm.org/D36747
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319649 91177308-0d34-0410-b5e6-96231b3b80d8
Two issues found when doing codegen for splitting vector with non-zero alloca addr space:
DAGTypeLegalizer::SplitVecRes_INSERT_VECTOR_ELT/SplitVecOp_EXTRACT_VECTOR_ELT uses dummy pointer info for creating
SDStore. Since one pointer operand contains multiply and add, InferPointerInfo is unable to
infer the correct pointer info, which ends up with a dummy pointer info for the target to lower
store and results in isel failure. The fix is to introduce MachinePointerInfo::getUnknownStack to
represent MachinePointerInfo which is known in alloca address space but without other information.
TargetLowering::getVectorElementPointer uses value type of pointer in addr space 0 for
multiplication of index and then add it to the pointer. However the pointer may be in an addr
space which has different size than addr space 0. The fix is to use the pointer value type for
index multiplication.
Differential Revision: https://reviews.llvm.org/D39758
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319622 91177308-0d34-0410-b5e6-96231b3b80d8
r230670 introduced a step to map EH register numbers to standard
DWARF register numbers. This failed to consider the case when a
user .cfi_* directive uses an integer literal rather than a
register name, to specify a DWARF register number that has no
corresponding LLVM register number (e.g. a special register that
the compiler and assembler have no name for).
Fixes PR34028.
Patch by Roland McGrath
Differential Revision: https://reviews.llvm.org/D36493
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319586 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
When debugging function passes it happens to be rather useful to dump
the whole module before the transformation and then use this dump
to analyze this single transformation by running it separately
on that particular module state.
Introducing
-print-module-scope
debugging option that forces all the function-level IR dumps
to become whole-module dumps.
This option builds on top of normal dumping controls like
-print-before/after
-filter-print-funcs
The plan is to eventually extend this option to cover other local passes
(at least loop passes) but that should go as a separate change.
Reviewers: sanjoy, weimingz, silvas, fedor.sergeev
Reviewed By: weimingz
Subscribers: apilipenko, skatkov, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D40245
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@319561 91177308-0d34-0410-b5e6-96231b3b80d8
