| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change reverts r318575 and changes FindDynamicShadowStart() to
keep the memory range it found mapped PROT_NONE to make sure it is
not reused. We also skip MemoryRangeIsAvailable() check, because it
is (a) unnecessary, and (b) would fail anyway.
Reviewers: pcc, vitalybuka, kcc
Subscribers: srhines, kubamracek, mgorny, llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D40203
llvm-svn: 318666
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The instructions addis,addi, bl are used to calculate the address of TLS thread
local variables. These TLS access code sequences are generated repeatedly every
time the thread local variable is accessed. By communicating to Machine CSE that
X2 is guaranteed to have the same value within the same function call (so called
Caller Preserved Physical Register), the redundant TLS access code sequences are
cleaned up.
Differential Revision: https://reviews.llvm.org/D39173
llvm-svn: 318661
|
| |
|
|
|
|
|
|
|
| |
Move the hazard scheduling pass to after the long branch pass, as the
long branch pass can create forbiddden slot hazards. Rather than complicating
the implementation of the long branch pass to handle forbidden slot hazards,
just reorder the passes.
llvm-svn: 318657
|
| |
|
|
|
|
|
|
| |
The 32 bit subreg indices of GR128 registers must also be checked for in
getRC32().
Review: Ulrich Weigand.
llvm-svn: 318652
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The VSX versions have the advantage of a full 64-register target whereas the FP
ones have the advantage of lower latency and higher throughput. So what we’re
after is using the faster instructions in low register pressure situations and
using the larger register file in high register pressure situations.
The heuristic chooses between the following 7 pairs of instructions.
PPC::LXSSPX vs PPC::LFSX
PPC::LXSDX vs PPC::LFDX
PPC::STXSSPX vs PPC::STFSX
PPC::STXSDX vs PPC::STFDX
PPC::LXSIWAX vs PPC::LFIWAX
PPC::LXSIWZX vs PPC::LFIWZX
PPC::STXSIWX vs PPC::STFIWX
Differential Revision: https://reviews.llvm.org/D38486
llvm-svn: 318651
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch fixes an issue so that the right alias is printed when the instruction has tied operands. It checks the number of operands in the resulting instruction as opposed to the alias, and then skips over tied operands that should not be printed in the alias.
This allows to generate the preferred assembly syntax for the AArch64 'ins' instruction, which should always be displayed as 'mov' according to the ARM Architecture Reference Manual. Several unit tests have changed as a result, but only to reflect the preferred disassembly. Some other InstAlias patterns (movk/bic/orr) needed a slight adjustment to stop them becoming the default and breaking other unit tests.
Please note that the patch is mostly the same as https://reviews.llvm.org/D29219 which was reverted because of an issue found when running TableGen with the Address Sanitizer. That issue has been addressed in this iteration of the patch.
Reviewers: rengolin, stoklund, huntergr, SjoerdMeijer, rovka
Reviewed By: rengolin, SjoerdMeijer
Subscribers: fhahn, aemerson, javed.absar, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D40030
llvm-svn: 318650
|
| |
|
|
|
|
|
|
| |
(experimental)
Differential revision: https://reviews.llvm.org/D39897
llvm-svn: 318649
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a new abstraction layer to VPlan and leverages it to model the planned
instructions that manipulate masks (AND, OR, NOT), introduced during predication.
The new VPValue and VPUser classes model how data flows into, through and out
of a VPlan, forming the vertices of a planned Def-Use graph. The new
VPInstruction class is a generic single-instruction Recipe that models a
planned instruction along with its opcode, operands and users. See
VectorizationPlan.rst for more details.
Differential Revision: https://reviews.llvm.org/D38676
llvm-svn: 318645
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch depends on: https://reviews.llvm.org/D35348
Support of pattern selection of masked gathers of AVX2 (X86\AVX2 code gen)
Update LoopVectorize to generate gathers for AVX2 processors.
Reviewers: delena, zvi, RKSimon, craig.topper, aaboud, igorb
Reviewed By: delena, RKSimon
Differential Revision: https://reviews.llvm.org/D35772
llvm-svn: 318641
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In rL316552, we ban intersection of unsigned latch range with signed range check and vice
versa, unless the entire range check iteration space is known positive. It was a correct
functional fix that saved us from dealing with ambiguous values, but it also appeared
to be a very restrictive limitation. In particular, in the following case:
loop:
%iv = phi i32 [ 0, %preheader ], [ %iv.next, %latch]
%iv.offset = add i32 %iv, 10
%rc = icmp slt i32 %iv.offset, %len
br i1 %rc, label %latch, label %deopt
latch:
%iv.next = add i32 %iv, 11
%cond = icmp i32 ult %iv.next, 100
br it %cond, label %loop, label %exit
Here, the unsigned iteration range is `[0, 100)`, and the safe range for range
check is `[-10, %len - 10)`. For unsigned iteration spaces, we use unsigned
min/max functions for range intersection. Given this, we wanted to avoid dealing
with `-10` because it is interpreted as a very big unsigned value. Semantically, range
check's safe range goes through unsigned border, so in fact it is two disjoint
ranges in IV's iteration space. Intersection of such ranges is not trivial, so we prohibited
this case saying that we are not allowed to intersect such ranges.
What semantics of this safe range actually means is that we can start from `-10` and go
up increasing the `%iv` by one until we reach `%len - 10` (for simplicity let's assume that
`%len - 10` is a reasonably big positive value).
In particular, this safe iteration space includes `0, 1, 2, ..., %len - 11`. So if we were able to return
safe iteration space `[0, %len - 10)`, we could safely intersect it with IV's iteration space. All
values in this range are non-negative, so using signed/unsigned min/max for them is unambiguous.
In this patch, we alter the algorithm of safe range calculation so that it returnes a subset of the
original safe space which is represented by one continuous range that does not go through wrap.
In order to reach this, we use modified SCEV substraction function. It can be imagined as a function
that substracts by `1` (or `-1`) as long as the further substraction does not cause a wrap in IV iteration
space. This allows us to perform IRCE in many situations when we deal with IV space and range check
of different types (in terms of signed/unsigned).
We apply this approach for both matching and not matching types of IV iteration space and the
range check. One implication of this is that now IRCE became smarter in detection of empty safe
ranges. For example, in this case:
loop:
%iv = phi i32 [ %begin, %preheader ], [ %iv.next, %latch]
%iv.offset = sub i32 %iv, 10
%rc = icmp ult i32 %iv.offset, %len
br i1 %rc, label %latch, label %deopt
latch:
%iv.next = add i32 %iv, 11
%cond = icmp i32 ult %iv.next, 100
br it %cond, label %loop, label %exit
If `%len` was less than 10 but SCEV failed to trivially prove that `%begin - 10 >u %len- 10`,
we could end up executing entire loop in safe preloop while the main loop was still generated,
but never executed. Now, cutting the ranges so that if both `begin - 10` and `%len - 10` overflow,
we have a trivially empty range of `[0, 0)`. This in some cases prevents us from meaningless optimization.
Differential Revision: https://reviews.llvm.org/D39954
llvm-svn: 318639
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We must collect all AddModes even if they are the same.
This is due to Original value is different but we need all original
values collected as they are used as anchors in common phi finding.
Reviewers: john.brawn, reames
Reviewed By: john.brawn
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40166
llvm-svn: 318638
|
| |
|
|
|
|
|
|
| |
getX86CpuIDAndInfoEx.
This leaf doesn't take an additional argument.
llvm-svn: 318634
|
| |
|
|
|
|
| |
keep the bits in order per register and encourage future additions to be in order too.
llvm-svn: 318633
|
| |
|
|
| |
llvm-svn: 318629
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
As the first test shows, we could transform an llvm intrinsic which never sets errno
into a libcall which could set errno (even though it's marked readnone?), so that's
not ideal.
It's possible that we can also transform a libcall which could set errno to an
intrinsic given the fast-math-flags constraint, but that's deferred to determine
exactly which set of FMF are needed.
Differential Revision: https://reviews.llvm.org/D40150
llvm-svn: 318628
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'ord' and 'uno' predicates have a logic operation for NAN built into their definitions:
FCMP_ORD = 7, ///< 0 1 1 1 True if ordered (no nans)
FCMP_UNO = 8, ///< 1 0 0 0 True if unordered: isnan(X) | isnan(Y)
So we can simplify patterns like this:
(fcmp ord (known NNAN), X) && (fcmp ord X, Y) --> fcmp ord X, Y
(fcmp uno (known NNAN), X) || (fcmp uno X, Y) --> fcmp uno X, Y
It might be better to split this into (X uno 0) | (Y uno 0) as a canonicalization, but that
would be another patch.
Differential Revision: https://reviews.llvm.org/D40130
llvm-svn: 318627
|
| |
|
|
|
|
| |
Also fix the memop in the ins for these instructions. Not sure what effect this has.
llvm-svn: 318624
|
| |
|
|
|
|
| |
sse_load_f32/f64.
llvm-svn: 318623
|
| |
|
|
|
| |
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
llvm-svn: 318615
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
kernel verifier is becoming smarter and soon will support
direct and indirect function calls.
Remove obsolete error from BPF backend.
Make call to use PCRel_4 fixup.
'bpf to bpf' calls are distinguished from 'bpf to kernel' calls
by insn->src_reg == BPF_PSEUDO_CALL == 1 which is used as relocation
indicator similar to ld_imm64->src_reg == BPF_PSEUDO_MAP_FD == 1
The actual 'call' instruction remains the same for both
'bpf to kernel' and 'bpf to bpf' calls.
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
llvm-svn: 318614
|
| |
|
|
|
|
|
|
| |
Haswell.
Cannonlake comes after skylake and supports avx512 so this is probably a closer model for now.
llvm-svn: 318613
|
| |
|
|
|
|
| |
There are several patches out for review right now to implement Icelake features. This adds a CPU to collect them under.
llvm-svn: 318612
|
| |
|
|
| |
llvm-svn: 318611
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The CodeGenCoverage.h header is installed, but it references
the build-only header "llvm/Config/config.h". This breaks use
of the CodeGenCoverage.h header once it is installed, because config.h isn't
available.
This patch fixes the error by moving the config.h include from
the CodeGenCoverage.h header (where it's not needed), to the
CodeGenCoverage.cpp source file.
llvm-svn: 318602
|
| |
|
|
|
|
| |
We don't need a dyn_cast, the predicate already specified the base node. We only need to check the type of the index, the base ptr is guaranteed to be scalar.
llvm-svn: 318596
|
| |
|
|
|
|
| |
I'm playing around with this flag and these places cause errors if not qualified.
llvm-svn: 318595
|
| |
|
|
|
|
| |
As discussed on PR35295, but it causes regressions in combineSubToSubus which need to be addressed first
llvm-svn: 318594
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
With this patch I tried to reduce the complexity of the code sightly, by
removing some indirection. Please let me know what you think.
Reviewers: junbuml, mcrosier, davidxl
Reviewed By: junbuml
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40037
llvm-svn: 318593
|
| |
|
|
|
|
|
|
|
|
| |
This makes sure that functions that only clobber xmm registers
(on win64) also get the right cfi directives, if dwarf exceptions
are enabled.
Differential Revision: https://reviews.llvm.org/D40191
llvm-svn: 318591
|
| |
|
|
| |
llvm-svn: 318590
|
| |
|
|
|
|
|
|
|
| |
We used to detect loads feeding fp instructions, but we were
failing to take into account cases where this happens through copies.
For instance, loads can fed copies coming from the ABI lowering
of floating point arguments/results.
llvm-svn: 318589
|
| |
|
|
|
|
|
|
|
| |
We used to detect that stores were fed by fp instructions, but we were
failing to take into account cases where this happens through copies.
For instance, stores can be fed by copies coming from the ABI lowering
of floating point arguments.
llvm-svn: 318588
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mappings
Instead of asserting that the type sizes are exactly equal, we check
that the new size is big enough to contain the original type.
We have to relax this constrain because, right now, we sometimes
specify that things that are smaller than a storage type are legal
instead of widening everything to the size of a storage type.
E.g., we say that G_AND s16 is legal and we map that on GPR32.
This is something we may revisit in the future (either by changing
the legalization process or keeping track separately of the storage
size and the size of the type), but let us reflect the reality of
the situation for now.
llvm-svn: 318587
|
| |
|
|
|
|
|
|
|
| |
cross copies
Turns out this copies can actually occur because of the way we lower the
ABI for half.
llvm-svn: 318586
|
| |
|
|
| |
llvm-svn: 318584
|
| |
|
|
|
|
|
| |
By having an UTF-16 version we avoid some code duplication in calling
GetFinalPathNameByHandleW.
llvm-svn: 318583
|
| |
|
|
|
|
|
|
|
| |
We were not doing that for large shadow granularity. Also add more
stack frame layout tests for large shadow granularity.
Differential Revision: https://reviews.llvm.org/D39475
llvm-svn: 318581
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Revert the following commits:
r318369 [asan] Fallback to non-ifunc dynamic shadow on android<22.
r318235 [asan] Prevent rematerialization of &__asan_shadow.
r317948 [sanitizer] Remove unnecessary attribute hidden.
r317943 [asan] Use dynamic shadow on 32-bit Android.
MemoryRangeIsAvailable() reads /proc/$PID/maps into an mmap-ed buffer
that may overlap with the address range that we plan to use for the
dynamic shadow mapping. This is causing random startup crashes.
llvm-svn: 318575
|
| |
|
|
|
|
|
|
|
|
| |
true.
Differential Revision: https://reviews.llvm.org/D39737
This is the second attempt to commit this. The test was broken on Linux in the first attempt.
llvm-svn: 318560
|
| |
|
|
|
|
|
|
|
|
| |
This is mostly moving VMEM clause breaking into
the hazard recognizer. Also move another hazard
currently handled in the waitcnt pass.
Also stops breaking clauses unless xnack is enabled.
llvm-svn: 318557
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This change fix PR35342 by replacing only the current use with undef in unreachable blocks.
Reviewers: efriedma, mcrosier, igor-laevsky
Reviewed By: efriedma
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40184
llvm-svn: 318551
|
| |
|
|
|
|
|
|
|
| |
This move some of the complexity over to the lower level TempFile.
It also makes it a bit more explicit where errors are ignored since we
now have a call to consumeError.
llvm-svn: 318550
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
making it no longer even remotely simple.
The pass will now be more of a "full loop unswitching" pass rather than
anything substantively simpler than any other approach. I plan to rename
it accordingly once the dust settles.
The key ideas of the new loop unswitcher are carried over for
non-trivial unswitching:
1) Fully unswitch a branch or switch instruction from inside of a loop to
outside of it.
2) Update the CFG and IR. This avoids needing to "remember" the
unswitched branches as well as avoiding excessively cloning and
reliance on complex parts of simplify-cfg to cleanup the cfg.
3) Update the analyses (where we can) rather than just blowing them away
or relying on something else updating them.
Sadly, #3 is somewhat compromised here as the dominator tree updates
were too complex for me to want to reason about. I will need to make
another attempt to do this now that we have a nice dynamic update API
for dominators. However, we do adhere to #3 w.r.t. LoopInfo.
This approach also adds an important principls specific to non-trivial
unswitching: not *all* of the loop will be duplicated when unswitching.
This fact allows us to compute the cost in terms of how much *duplicate*
code is inserted rather than just on raw size. Unswitching conditions
which essentialy partition loops will work regardless of the total loop
size.
Some remaining issues that I will be addressing in subsequent commits:
- Handling unstructured control flow.
- Unswitching 'switch' cases instead of just branches.
- Moving to the dynamic update API for dominators.
Some high-level, interesting limitationsV that folks might want to push
on as follow-ups but that I don't have any immediate plans around:
- We could be much more clever about not cloning things that will be
deleted. In fact, we should be able to delete *nothing* and do
a minimal number of clones.
- There are many more interesting selection criteria for which branch to
unswitch that we might want to look at. One that I'm interested in
particularly are a set of conditions which all exit the loop and which
can be merged into a single unswitched test of them.
Differential revision: https://reviews.llvm.org/D34200
llvm-svn: 318549
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a vreg's bank is specified in the registers block and one of its
defs or uses also specifies the bank, we end up checking that the
RegBank is equal to diagnose conflicting banks. The problem comes up
for generic vregs, where we weren't fully initializing the VRegInfo
when parsing the registers block, so we'd end up comparing a null
pointer to uninitialized memory.
This fixes a non-deterministic failure when round tripping through MIR
with generic vregs.
llvm-svn: 318543
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The assertion was introduced in r317853 but there are cases when a call
isn't handled either as direct or indirect. In this case we add a
reference graph edge but not a call graph edge.
Reviewers: tejohnson
Reviewed By: tejohnson
Subscribers: mehdi_amini, inglorion, eraman, hiraditya, efriedma, llvm-commits
Differential Revision: https://reviews.llvm.org/D40056
llvm-svn: 318540
|
| |
|
|
|
|
|
|
|
|
| |
set to true."
This reverts commit r318528.
MC/AsmParser/preserve-comments-crlf.s fails on linux.
llvm-svn: 318533
|
| |
|
|
|
|
| |
Improve the accuracy of the model by specifying the proper number of uops.
llvm-svn: 318531
|
| |
|
|
|
|
|
|
| |
true.
Differential Revision: https://reviews.llvm.org/D39737
llvm-svn: 318528
|
| |
|
|
|
|
|
|
|
|
| |
See bug 35148: https://bugs.llvm.org//show_bug.cgi?id=35148
Reviewers: tamazov, SamWot, arsenm
Differential Revision: https://reviews.llvm.org/D39492
llvm-svn: 318526
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed broken comparison.
borked by: rL284966 (see: https://reviews.llvm.org/D25730).
Differential Revision: https://reviews.llvm.org/D40119
This is a second attempt to commit this.
The first attempt broke lld and gold tests that had been written against
the incorrect behaivour.
llvm-svn: 318524
|