| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
We are also free to interpret this as 'BZHI'/'BEXTR'.
https://rise4fun.com/Alive/dD6
llvm-svn: 362325
|
| |
|
|
|
|
|
|
|
|
| |
bitcast(insert_subvector(x,y),c2)
Move this combine from x86 into generic DAGCombine, which currently only manages cases where the bitcast is between types of the same scalarsize.
Differential Revision: https://reviews.llvm.org/D59188
llvm-svn: 362324
|
| |
|
|
|
|
|
|
|
|
|
|
| |
undefs + truncation (PR41020)
Add (opt-in) support for implicit truncation to isConstOrConstSplat, which allows us to match truncated 'all ones' cases in isBitwiseNot.
PR41020 compares against using ISD::isBuildVectorAllOnes() instead, but that predicate silently accepts any UNDEF elements in the build vector which might not be what we want in isBitwiseNot - so I've added an opt-in 'AllowUndefs' flag that is set to false by default but will allow us to enable it on individual cases where its safe.
Differential Revision: https://reviews.llvm.org/D62783
llvm-svn: 362323
|
| |
|
|
|
|
|
|
| |
in analysis.
These might have been replaced in multiple use cases.
llvm-svn: 362322
|
| |
|
|
|
|
|
|
| |
SimplifyDemandedBits. NFCI.
Helps with debugging as we recurse between them.
llvm-svn: 362321
|
| |
|
|
|
|
| |
These saturating math ops can be replaced with simple math.
llvm-svn: 362320
|
| |
|
|
|
|
|
| |
If we look past truncations of X too eagerly (D62786), we may
end up with 64-bit 'BEXTR', even though 32-bit-one would suffice.
llvm-svn: 362319
|
| |
|
|
| |
llvm-svn: 362318
|
| |
|
|
|
|
| |
'this' capture initialization.
llvm-svn: 362317
|
| |
|
|
|
|
|
|
|
| |
regenerate the test expectations.
(Only two tests change, as a result of no longer matching the 0x in a
pointer; the other tests were already excluding that.)
llvm-svn: 362316
|
| |
|
|
|
|
|
|
|
|
| |
The results of the dyn_casts were immediately dereferenced on the next line
so they had better not be null.
I don't think there's any way for these dyn_casts to fail, so use a cast
of adding null check.
llvm-svn: 362315
|
| |
|
|
| |
llvm-svn: 362314
|
| |
|
|
|
|
|
|
|
|
|
|
| |
LLVM CMake build already uses libtool instead of ar when building
for Apple platform and we should be using the same when building
runtimes. To do so, this change extracts the logic for finding
libtool into a separate file and then uses it from both the LLVM
build as well as the LLVM runtimes build.
Differential Revision: https://reviews.llvm.org/D62769
llvm-svn: 362313
|
| |
|
|
|
|
|
|
|
|
| |
MachineInstr::print
Over a year ago, MachineInstr gained a fourth boolean parameter that occurs
before the TII pointer. When this happened, several places started accidentally
passing TII into this boolean parameter instead of the TII parameter.
llvm-svn: 362312
|
| |
|
|
|
|
|
|
|
|
| |
ar doesn't produce the correct results when used for linking static
archives on Apple platforms, so instead use libtool -static which is
the official way to build static archives on those platforms.
Differential Revision: https://reviews.llvm.org/D62770
llvm-svn: 362311
|
| |
|
|
|
|
|
|
| |
similar way to r362308.
Forgot to do the widen forms when I was doing the others.
llvm-svn: 362310
|
| |
|
|
| |
llvm-svn: 362309
|
| |
|
|
|
|
|
| |
The AVX512BW and AVX512VL checks were never used. And AVX512 is the same
as AVX on all tests that weren't already split for AVX1 and AVX2.
llvm-svn: 362308
|
| |
|
|
| |
llvm-svn: 362307
|
| |
|
|
| |
llvm-svn: 362306
|
| |
|
|
|
|
|
|
|
|
|
| |
Extract a willNotOverflow() helper function that is shared between
eliminateOverflowIntrinsic() and strengthenOverflowingOperation().
Use WithOverflowInst for the former.
We'll be able to reuse the same code for saturating intrinsics as
well.
llvm-svn: 362305
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fsub -0.0, %x
Summary: Fneg can be implemented with an xor rather than a function call so we don't need to add the function call overhead. This was pointed out in D62699
Reviewers: efriedma, cameron.mcinally
Reviewed By: efriedma
Subscribers: javed.absar, eraman, hiraditya, haicheng, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62747
llvm-svn: 362304
|
| |
|
|
| |
llvm-svn: 362303
|
| |
|
|
|
|
| |
pending set. NFCI
llvm-svn: 362302
|
| |
|
|
|
|
| |
In reality APInt::getBitsNeeded(INT_MIN, base) cases require one less bit than is returned
llvm-svn: 362301
|
| |
|
|
| |
llvm-svn: 362300
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `cfcmsa` and `ctcmsa` instructions accept index of MSA control
register. The MIPS64 SIMD Architecture define eight MSA control
registers. But register index for `cfcmsa` and `ctcmsa` instructions
might be any number in 0..31 range. If the index is greater then 7,
`cfcmsa` writes zero to the destination registers and `ctcmsa` does
nothing [1].
[1] MIPS Architecture for Programmers Volume IV-j:
The MIPS64 SIMD Architecture Module
https://www.mips.com/?do-download=the-mips64-simd-architecture-module
Differential Revision: https://reviews.llvm.org/D62597
llvm-svn: 362299
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If we would allow register coalescing on PTRDISPREGS class then register
allocator can lock Z register to some virtual register. Larger instructions
requiring a memory acces then fail during the register allocation phase since
there is no available register to hold a pointer if Y register was already
taken for a stack frame. This patch prevents it by keeping Z register
spillable. It does it by not allowing coalescer to lock it.
Original discussion on https://github.com/avr-rust/rust/issues/128.
llvm-svn: 362298
|
| |
|
|
| |
llvm-svn: 362297
|
| |
|
|
| |
llvm-svn: 362296
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
I have initially added it in for test to display both
whether the binop w/ constant is sinked or hoisted.
But as it can be seen from the 'sub (sub C, %x), %y'
test, that actually conceals the issues it is supposed to test.
At least two more patterns are unhandled:
* 'add (sub C, %x), %y' - D62266
* 'sub (sub C, %x), %y'
llvm-svn: 362295
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Delete aarch64-got.s because it is covered by aarch64-tls-iele.s
Merge got-aarch64.s into aarch64-fpic-got.s by adding disassembly to the latter
Create aarch64-gnu-ifunc-nonpreemptable to unify aarch64-gnu-ifunc3.s (position-dependent executable) and aarch64-gnu-ifunc-address-pie.s (PIE)
Rename aarch64-got-reloc.s to aarch64-got-weak-undef.s
Add --no-show-raw-insn to llvm-objdump -d RUN lines
Add -pie test to arch64-tls-iele.s
Delete aarch64-tls-pie.s: it is covered by arch64-tls-iele.s and aarch64-tls-le.s
Rename aarch64-copy2.s to aarch64-nopic-plt.s: "copy2" gives false impression that the test is related to copy relocation
llvm-svn: 362294
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Template back references used to be recursively recomputed, add a
memoization cache to cut down on this.
Since there are now two different types of argument maps, rename the
existing TypeBackReferences to FunArgBackReferences, and rename
mangleArgumentType() to mangleFunctionArgumentType().
Fixes PR42091, the input there now takes 50ms instead of 7s to compile.
No intended behavior change.
Differential Revision: https://reviews.llvm.org/D62746
llvm-svn: 362293
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix for https://bugs.llvm.org/show_bug.cgi?id=31181 and partial fix
for LFTR poison handling issues in general.
When LFTR moves a condition from pre-inc to post-inc, it may now
depend on value that is poison due to nowrap flags. To avoid this,
we clear any nowrap flag that SCEV cannot prove for the post-inc
addrec.
Additionally, LFTR may switch to a different IV that is dynamically
dead and as such may be arbitrarily poison. This patch will correct
nowrap flags in some but not all cases where this happens. This is
related to the adoption of IR nowrap flags for the pre-inc addrec.
(See some of the switch_to_different_iv tests, where flags are not
dropped or insufficiently dropped.)
Finally, there are likely similar issues with the handling of GEP
inbounds, but we don't have a test case for this yet.
Differential Revision: https://reviews.llvm.org/D60935
llvm-svn: 362292
|
| |
|
|
|
|
|
| |
Two more tests with a switch to a dynamically dead IV, with poison
occuring on the first or second iteration.
llvm-svn: 362291
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows the DWARFExpression class to handle addresses without
crashing on targets with 16-bit pointers like AVR.
This is required in order to generate assembly from clang via the '-S'
flag.
This fixes an error with the following message:
clang: llvm/include/llvm/DebugInfo/DWARF/DWARFExpression.h:132: llvm::DWARFExpression::DWARFExpression(llvm::DataExtractor, uint16_t, uint8_t):
Assertion `AddressSize == 8 || AddressSize == 4' failed.
llvm-svn: 362290
|
| |
|
|
| |
llvm-svn: 362289
|
| |
|
|
|
|
| |
folding tables.
llvm-svn: 362288
|
| |
|
|
|
|
|
|
|
| |
output to make it easier to diff.
Fix a few other formatting issues in the manual table. And remove some
old FIXMEs.
llvm-svn: 362287
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This was flagged in https://www.viva64.com/en/b/0629/ under "Snippet No.
33".
It seems that this statement is doing the standard bitwise trick for
adjusting a value to have a specific alignment.
The issue is that getStubAlignment() returns an unsigned, while DataSize
is declared a uint64_t. The right hand side of the expression is not
extended to 64b before bitwise negation, resulting in the top half of
the mask being 0s, which is not correct for realignment.
Reviewers: lhames, MaskRay
Reviewed By: MaskRay
Subscribers: RKSimon, MaskRay, hiraditya, llvm-commits, srhines
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62227
llvm-svn: 362286
|
| |
|
|
| |
llvm-svn: 362285
|
| |
|
|
| |
llvm-svn: 362284
|
| |
|
|
|
|
|
|
| |
ARM64 CodeView test was incorrectly put under test/DebugInfo/COFF folder which
runs for all all architectures. This fix moves it to a subfolder AArch64 with
lit.local.cfg which specify it supports AArch64 only.
llvm-svn: 362283
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At the moment, LoopPredication completely bails out if it sees a latch of the form:
%cmp = icmp ne %iv, %N
br i1 %cmp, label %loop, label %exit
OR
%cmp = icmp ne %iv.next, %NPlus1
br i1 %cmp, label %loop, label %exit
This is unfortunate since this is exactly the form that LFTR likes to produce. So, go ahead and recognize simple cases where we can.
For pre-increment loops, we leverage the fact that LFTR likes canonical counters (i.e. those starting at zero) and a (presumed) range fact on RHS to discharge the check trivially.
For post-increment forms, the key insight is in remembering that LFTR had to insert a (N+1) for the RHS. CVP can hopefully prove that add nsw/nuw (if there's appropriate range on N to start with). This leaves us both with the post-inc IV and the RHS involving an nsw/nuw add, and SCEV can discharge that with no problem.
This does still need to be extended to handle non-one steps, or other harder patterns of variable (but range restricted) starting values. That'll come later.
Differential Revision: https://reviews.llvm.org/D62748
llvm-svn: 362282
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were hashing the string pointer, not the string, so two instructions
could be identical (isIdenticalTo), but have different hash codes.
This showed up as a very rare, non-deterministic assertion failure
rehashing a DenseMap constructed by MachineOutliner. So there's no
"real" testcase, just a unittest which checks that the hash function
behaves correctly.
I'm a little scared fixing this is going to cause a regression in
outlining or MachineCSE, but hopefully we won't run into any issues.
Differential Revision: https://reviews.llvm.org/D61975
llvm-svn: 362281
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CodeView has its own register map which is defined in cvconst.h. Missing this
mapping before saving register to CodeView causes debugger to show incorrect
value for all register based variables, like variables in register and local
variables addressed by register (stack pointer + offset).
This change added mapping between LLVM register and CodeView register so the
correct register number will be stored to CodeView/PDB, it aso fixed the
mapping from CodeView register number to register name based on current
CPUType but print PDB to yaml still assumes X86 CPU and needs to be fixed.
Differential Revision: https://reviews.llvm.org/D62608
llvm-svn: 362280
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
guide.
Summary:
Revise the google-objc-global-variable-declaration check to match the style guide.
This commit updates the check as follows:
(1) Do not emit fixes for extern global constants.
(2) Allow the second character of prefixes for constants to be numeric (the new guideline is that global constants should generally be named with a prefix that begins with a capital letter followed by one or more capital letters or numbers).
https://google.github.io/styleguide/objcguide.html#prefixes
This is an amended re-submission of https://reviews.llvm.org/rG12e3726fadb0b2a4d8aeed0a2817b5159f9d029d.
Contributed By: yaqiji
Reviewers: Wizard, benhamilton, stephanemoore
Reviewed By: benhamilton, stephanemoore
Subscribers: mgorny, cfe-commits, yaqiji
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62045
llvm-svn: 362279
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
It looks like since INLINEASM_BR was created off of INLINEASM (r353563),
a few checks for INLINEASM needed to be updated to check for either
case.
pr/41999
Reviewers: hfinkel
Reviewed By: hfinkel
Subscribers: nemanjai, hiraditya, kbarton, jsji, llvm-commits, craig.topper, srhines
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62403
llvm-svn: 362278
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Testing with debuggers shows that our previous behavior was correct.
The reason I thought MSVC did things differently is that MSVC prefers to
use the 0xB combined code offset and code length update opcode when
inline sites are discontiguous.
Keep the test changes, and update the llvm-pdbutil inline line table
dumper to account for this new interpretation of the opcodes.
llvm-svn: 362277
|
| |
|
|
|
|
|
|
| |
These can still be exported via --export if needed.
Differential Revision: https://reviews.llvm.org/D62744
llvm-svn: 362276
|