| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 352331
|
| |
|
|
| |
llvm-svn: 352330
|
| |
|
|
| |
llvm-svn: 352329
|
| |
|
|
| |
llvm-svn: 352328
|
| |
|
|
|
|
|
| |
Some other transform is creating the opposite form and causing
an infinite loop if we try to split some of these.
llvm-svn: 352327
|
| |
|
|
| |
llvm-svn: 352326
|
| |
|
|
| |
llvm-svn: 352321
|
| |
|
|
|
|
|
| |
I expected this to be automatically verified, but it seems
nothing uses that the type index was declared as a "ptype"
llvm-svn: 352319
|
| |
|
|
|
|
|
|
| |
While i have no intention of actually commiting regeneration
of the check lines in these test files with update_llc_test_checks,
lack of that whitespace breaks that util, which is mildly inconvenient.
llvm-svn: 352318
|
| |
|
|
| |
llvm-svn: 352316
|
| |
|
|
|
|
| |
condition codes.
llvm-svn: 352314
|
| |
|
|
| |
llvm-svn: 352313
|
| |
|
|
|
|
|
| |
I reverted it originally due to a bot failing. The underlying bug has been fixed
as of r352311.
llvm-svn: 352312
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
illegal instructions.
This fixes loads like 's1 = load %p (load 1 from %p)' being combined with an
extend into an illegal 's8 = g_extload %p (load 1 from %p)' which doesn't do any
extension, by avoiding touching those < s8 size loads.
This bug was uncovered by a verifier update r351584, which I reverted it to keep
the bots green.
llvm-svn: 352311
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The add+and sequence followed by a branch can
happen e.g. when looping over the set bits of an integer:
```
while (x != 0) {
func(x & ~x);
x &= x - 1;
}
```
Reviewed By: ctopper
Differential Revision: https://reviews.llvm.org/D57296
llvm-svn: 352306
|
| |
|
|
| |
llvm-svn: 352305
|
| |
|
|
|
|
|
|
|
|
| |
produce SUBREG_TO_REG
def32 here means the producing instruction zeroed bits 63:32. We already do this for zext, but it looks like we can get an and+anyext sometimes.
Spotted in the diffs from D33587.
llvm-svn: 352303
|
| |
|
|
| |
llvm-svn: 352300
|
| |
|
|
| |
llvm-svn: 352298
|
| |
|
|
|
|
|
| |
When the fneg IR instruction was added the code to do translation wasn't
tested, and tried to get an invalid operand.
llvm-svn: 352296
|
| |
|
|
| |
llvm-svn: 352295
|
| |
|
|
| |
llvm-svn: 352294
|
| |
|
|
|
|
|
|
|
|
| |
(PR24545)
As discussed on PR24545, we should try to commute X86::COND_A 'icmp ugt' cases to X86::COND_B 'icmp ult' to more optimally bind the carry flag output to a SBB instruction.
Differential Revision: https://reviews.llvm.org/D57281
llvm-svn: 352289
|
| |
|
|
|
|
|
|
|
|
| |
We often generate X86ISD::SBB(X, 0) for carry flag arithmetic.
I had tried to create test cases for the ADC equivalent (which often uses the same pattern) but haven't managed to find anything yet.
Differential Revision: https://reviews.llvm.org/D57169
llvm-svn: 352288
|
| |
|
|
|
|
| |
update_llc_test_checks.py . NFC
llvm-svn: 352285
|
| |
|
|
|
|
| |
vectors (PR39859)
llvm-svn: 352283
|
| |
|
|
|
|
| |
(PR39859)
llvm-svn: 352281
|
| |
|
|
| |
llvm-svn: 352274
|
| |
|
|
| |
llvm-svn: 352272
|
| |
|
|
|
|
| |
have been previously removed.
llvm-svn: 352271
|
| |
|
|
|
|
|
|
| |
passthru argument.
We have unmasked versions as of r352172
llvm-svn: 352270
|
| |
|
|
|
|
|
|
| |
loads in the type legalizer"
This might be breaking an lldb windows buildbot.
llvm-svn: 352268
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cvt(u)dqtops intrinsics. Add new variadic uitofp/sitofp with rounding mode intrinsics.
Summary: See clang patch D56998 for a full description.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D56999
llvm-svn: 352266
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The IR enforced limit for the address space is 24-bits, but LLT was
only using 23-bits. Additionally, the argument to the constructor was
truncating to 16-bits.
A similar problem still exists for the number of vector elements. The
IR enforces no limit, so if you try to use a vector with > 65535
elements the IRTranslator asserts in the LLT constructor.
llvm-svn: 352264
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
conversion operations that only write the lower 64-bits of an xmm register and zero the rest.
Summary: We have isel patterns for this, but we're missing some load patterns and all broadcast patterns. A DAG combine seems like a better fit for this.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D56971
llvm-svn: 352260
|
| |
|
|
|
|
|
|
|
|
|
|
| |
IntrInaccessibleMemOnly attribute.
These intrinsics may return different values every time they are called
and should not be CSE'd. IntrInaccessibleMemOnly appears to be the right
attribute to model this behavior.
Differential Revision: https://reviews.llvm.org/D57259
llvm-svn: 352256
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
type legalizer
Summary:
I'm not sure why we were using SEXTLOAD. EXTLOAD seems more appropriate since we don't care about the upper bits.
This patch changes this and then modifies the X86 post legalization combine to emit a extending shuffle instead of a sign_extend_vector_inreg. Could maybe use an any_extend_vector_inreg, but I just did what we already do in LowerLoad. I think we can actually get rid of this code entirely if we switch to -x86-experimental-vector-widening-legalization.
On AVX512 targets I think we might be able to use a masked vpmovzx and not have to expand this at all.
Reviewers: RKSimon, spatel
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D57186
llvm-svn: 352255
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
DAGCombiner::visitBITCAST will perform:
fold (bitconvert (fneg x)) -> (xor (bitconvert x), signbit)
fold (bitconvert (fabs x)) -> (and (bitconvert x), (not signbit))
As shown in double-bitmanip-dagcombines.ll, this can be advantageous. But
RV32FD doesn't use bitcast directly (as i64 isn't a legal type), and instead
uses RISCVISD::SplitF64. This patch adds an equivalent DAG combine for
SplitF64.
llvm-svn: 352247
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently, if an instruction with a memory operand has no debug information,
X86DiscriminateMemOps will generate one based on the first line of the
enclosing function, or the last seen debug info.
This may cause confusion in certain debugging scenarios. The long term
approach would be to use the line number '0' in such cases, however, that
brings in challenges: the base discriminator value range is limited
(4096 values).
For the short term, adding an opt-in flag for this feature.
See bug 40319 (https://bugs.llvm.org/show_bug.cgi?id=40319)
Reviewers: dblaikie, jmorse, gbedwell
Reviewed By: dblaikie
Subscribers: aprantl, eraman, hiraditya
Differential Revision: https://reviews.llvm.org/D57257
llvm-svn: 352246
|
| |
|
|
|
|
|
|
| |
(fcopysign a, (fneg b)) will be expanded to bitwise operations by
DAGTypeLegalizer::SoftenFloatRes_FCOPYSIGN if the floating point type isn't
legal. Arguably it might be worth doing a combine even if it is legal.
llvm-svn: 352240
|
| |
|
|
|
|
| |
This reapplies commit r352010 with RISC-V test fixes.
llvm-svn: 352237
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If bottom of block BB has only one successor OldTop, in most cases it is profitable to move it before OldTop, except the following case:
-->OldTop<-
| . |
| . |
| . |
---Pred |
| |
BB-----
Move BB before OldTop can't reduce the number of taken branches, this patch detects this case and prevent the moving.
Differential Revision: https://reviews.llvm.org/D57067
llvm-svn: 352236
|
| |
|
|
|
|
|
|
|
|
| |
We also need to combine to masked truncating with saturation stores, but I'm leaving that for a future patch.
This does regress some tests that used truncate wtih saturation followed by a masked store. Those now use a truncating store and use min/max to saturate.
Differential Revision: https://reviews.llvm.org/D57218
llvm-svn: 352230
|
| |
|
|
|
|
|
| |
The intrinsic names erroneously used the .f32 variant. As the return and
argument types were still double the intrinsics calls worked properly.
llvm-svn: 352211
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Simplify to the generic ISD::ADD/SUB if we don't make use of the result flag.
This mainly helps with ADDCARRY/SUBBORROW intrinsics which get expanded to X86ISD::ADD/SUB but could be simplified further.
Noticed in some of the test cases in PR31754
Differential Revision: https://reviews.llvm.org/D57234
llvm-svn: 352210
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This isn't the final fix for our reduction/horizontal codegen, but it takes care
of a lot of the problems. After we narrow the shuffle, existing combines for
insert/extract and binops kick in, and we end up with cheaper 128-bit ops.
The avg and mul reduction tests show an existing shuffle lowering hole for
AVX2/AVX512. I think in its most minimal form this is:
https://bugs.llvm.org/show_bug.cgi?id=40434
...but we might need multiple fixes to get it right.
Differential Revision: https://reviews.llvm.org/D57156
llvm-svn: 352209
|
| |
|
|
|
|
|
|
|
| |
This target-independent code won't trigger for cases such as RV32FD where
custom SelectionDAG nodes are generated. These new tests demonstrate such
cases. Additionally, float-arith.ll was updated so that fneg.s, fsgnjn.s, and
fabs.s selection patterns are actually exercised.
llvm-svn: 352199
|
| |
|
|
|
|
| |
Show failure to simplify cases with zero op/flags
llvm-svn: 352196
|
| |
|
|
|
|
|
|
|
|
| |
Same as ARM.
On this occasion we split some of the instruction select tests for more
complicated instructions into their own files, so we can reuse them for
ARM and Thumb mode. Likewise for the legalizer tests.
llvm-svn: 352188
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Align checks for absolute addressing mode with its current
implementation (SR is used as a base register).
This fixes https://bugs.llvm.org/show_bug.cgi?id=39993
Patch by Kristina Bessonova!
Differential Revision: https://reviews.llvm.org/D56785
llvm-svn: 352178
|