| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 292328
|
| |
|
|
|
|
| |
build bot.
llvm-svn: 292327
|
| |
|
|
| |
llvm-svn: 292325
|
| |
|
|
|
|
|
| |
The grow_memory instruction now returns the previous memory size. Add the
return type to the LLVM intrinsic.
llvm-svn: 292322
|
| |
|
|
|
|
|
|
|
|
|
| |
You can now define the register class of a virtual register on the
operand itself avoiding the need to use a "registers:" block.
Example: "%0:gr64 = COPY %rax"
Differential Revision: https://reviews.llvm.org/D22398
llvm-svn: 292321
|
| |
|
|
|
|
| |
warnings; other minor fixes (NFC).
llvm-svn: 292320
|
| |
|
|
| |
llvm-svn: 292319
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: tra, majnemer
Subscribers: llvm-commits, jholewinski
Differential Revision: https://reviews.llvm.org/D28825
llvm-svn: 292316
|
| |
|
|
| |
llvm-svn: 292310
|
| |
|
|
|
|
|
| |
Some instructions were printed as "foo\tbar", but most are printed as
"foo \bar". Standardize on the latter form.
llvm-svn: 292306
|
| |
|
|
|
|
|
| |
!strconcat is a variadic function; it will concatenate an arbitrary
number of strings. There's no need to nest it.
llvm-svn: 292305
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change also lets us use max.{s,u}16. There's a vague warning in a
test about this maybe being less efficient, but I could not come up with
a case where the resulting SASS (sm_35 or sm_60) was different with or
without max.{s,u}16. It's true that nvcc seems to emit only
max.{s,u}32, but even ptxas 7.0 seems to have no problem generating
efficient SASS from max.{s,u}16 (the casts up to i32 and back down to
i16 seem to be implicit and nops, happening via register aliasing).
In the absence of evidence, better to have fewer special cases, emit
more straightforward code, etc. In particular, if a new GPU has 16-bit
min/max instructions, we want to be able to use them.
Reviewers: tra
Subscribers: jholewinski, llvm-commits
Differential Revision: https://reviews.llvm.org/D28732
llvm-svn: 292304
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Previously we lowered it literally, to shifts and xors.
Reviewers: tra
Subscribers: jholewinski, llvm-commits
Differential Revision: https://reviews.llvm.org/D28722
llvm-svn: 292303
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Avoid an unnecessary conversion operation when using the result of
ctpop.i32 or ctpop.i16 as an i32, as in both cases the ptx instruction
we run returns an i32.
(Previously if we used the value as an i32, we'd do an unnecessary
zext+trunc.)
Reviewers: tra
Subscribers: jholewinski, llvm-commits
Differential Revision: https://reviews.llvm.org/D28721
llvm-svn: 292302
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: tra
Subscribers: llvm-commits, jholewinski
Differential Revision: https://reviews.llvm.org/D28720
llvm-svn: 292301
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
* Disable "ctlz speculation", which inserts a branch on every ctlz(x) which
has defined behavior on x == 0 to check whether x is, in fact zero.
* Add DAG patterns that avoid re-truncating or re-expanding the result
of the 16- and 64-bit ctz instructions.
Reviewers: tra
Subscribers: llvm-commits, jholewinski
Differential Revision: https://reviews.llvm.org/D28719
llvm-svn: 292299
|
| |
|
|
| |
llvm-svn: 292295
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Threshold in loop unorller.
Summary: Partial unrolling should have separate threshold with full unrolling.
Reviewers: efriedma, mzolotukhin
Reviewed By: efriedma, mzolotukhin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28831
llvm-svn: 292293
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The patch is to solve the performance problem described in PR27827.
Register coalescing sometimes cannot remove a copy because of interference.
But if we can find a reverse copy in one of the predecessor block of the copy,
the copy is partially redundent and we may remove the copy partially by moving
it to the predecessor block without the reverse copy.
Differential Revision: https://reviews.llvm.org/D28585
llvm-svn: 292292
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: The causes google/ossfuzz#84
Reviewers: kcc
Subscribers: mgorny
Differential Revision: https://reviews.llvm.org/D28827
llvm-svn: 292289
|
| |
|
|
|
|
| |
code between cmp and memcmp handling)
llvm-svn: 292287
|
| |
|
|
|
|
| |
use-after-scope in mutator tests
llvm-svn: 292286
|
| |
|
|
|
|
| |
As with G_ICMP we'd written the CSET instructions backwards.
llvm-svn: 292285
|
| |
|
|
| |
llvm-svn: 292284
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Some platforms (notably iOS) use a different calling convention for unnamed vs
named parameters in varargs functions, so we need to keep track of this
information when translating calls.
Since not many platforms are involved, the guts of the special handling is in
the ValueHandler class (with a generic implementation that should work for most
targets).
llvm-svn: 292283
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unique exit block if available rather than rolling it ourselves.
This is a little disappointing because that helper doesn't do anything
clever to short-circuit the (surprisingly expensive) computation of all
exit blocks. What's worse is that the way we compute this is hopelessly,
hilariously inefficient. We're literally computing the same information
two different ways and multiple times each way:
- hasDedicatedExits computes the exit block set and then looks at the
predecessors of each
- getExitingBlocks computes the set of loop blocks which have exiting
successors
- getUniqueExitBlock(s) computes the set of non-loop blocks reached from
loop blocks (sound familiar?)
Anyways, at some point we should clean all of this up in the LoopInfo
API, but for now just simplifying the user I'm about to touch.
llvm-svn: 292282
|
| |
|
|
|
|
| |
conventions, missed this one in a previous cleanup patch (sorry).
llvm-svn: 292279
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Correctly populating Machine PHIs relies on knowing exactly how the IR level
CFG was lowered to MachineIR. This needs to be tracked by any translation
phases that meddle (currently only SwitchInst handling).
This reapplies r291973 which was reverted because of testing failures. Fixes:
+ Don't return an ArrayRef to a local temporary.
+ Incorporate Kristof's suggested comment improvements.
llvm-svn: 292278
|
| |
|
|
|
|
|
|
|
|
| |
I hope that for any code, it is changed only with good reason and only
when the author knows what they are doing...
There is of course good reason to comment here about the subtlety of the
process, and I've left that comment in tact.
llvm-svn: 292275
|
| |
|
|
|
|
|
|
|
|
|
|
| |
instead of members.
No state was being provided by the object so this seems strictly
simpler.
I've also tried to improve the name and comments for the functions to
more thoroughly document what they are doing.
llvm-svn: 292274
|
| |
|
|
|
|
|
|
|
|
|
| |
that we know has exactly one element when all we are going to do is get
that one element out of it.
Instead, pass around that one element.
There are more simplifications to come in this code...
llvm-svn: 292273
|
| |
|
|
|
|
|
| |
conventions more conistently before hacking on this code to integrate
nicely with new PM's loop pass infrastructure. NFC.
llvm-svn: 292272
|
| |
|
|
|
|
|
| |
This reduces the size of and increases the symmetry with the planned functional change in:
https://reviews.llvm.org/D28406
llvm-svn: 292260
|
| |
|
|
|
| |
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
llvm-svn: 292258
|
| |
|
|
|
|
|
|
|
|
|
| |
If a memory instruction will be vectorized, but it's pointer operand is
non-consecutive-like, the instruction is a gather or scatter operation. Its
pointer operand will be non-uniform. This should fix PR31671.
Reference: https://llvm.org/bugs/show_bug.cgi?id=31671
Differential Revision: https://reviews.llvm.org/D28819
llvm-svn: 292254
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D26701
llvm-svn: 292252
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Depends on D28740
Reviewers: dberlin, chandlerc, hfinkel, majnemer
Subscribers: mcrosier, llvm-commits
Differential Revision: https://reviews.llvm.org/D28741
llvm-svn: 292249
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
r292188 confused MSVC because of the combined lack of a default
case and return statement.
Move the unreachable outside of the NumLibFuncs case, to make it
obvious that all cases should be handled.
llvm_unreachable is __declspec(noreturn), so I'm assuming this
does appease MSVC.
llvm-svn: 292246
|
| |
|
|
| |
llvm-svn: 292244
|
| |
|
|
|
|
|
|
| |
Even with the fix from r291630, this still causes problems. I get
widespread assertion failures in the Swift runtime's WeakRefCount::increment()
function. I sent a reduced testcase in reply to the commit.
llvm-svn: 292242
|
| |
|
|
|
|
|
|
| |
Also, add the corresponding match to the AssumptionCache's 'Affected Values' list.
Differential Revision: https://reviews.llvm.org/D28485
llvm-svn: 292239
|
| |
|
|
|
|
|
| |
This further extends r292179 to support additional binary operators
beyond subtraction.
llvm-svn: 292238
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D28780
llvm-svn: 292233
|
| |
|
|
| |
llvm-svn: 292230
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instead of custom status"
No any changes, will follow up with D28807 commit containing APLi change for clang
to fix build issues happened.
Original commit message:
[Support/Compression] - Change zlib API to return Error instead of custom status.
Previously API returned custom enum values.
Patch changes it to return Error with string description.
That should help users to report errors in universal way.
Differential revision: https://reviews.llvm.org/D28684
llvm-svn: 292226
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: vpykhtin, artem.tamazov, tstellarAMD
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, tony-tye
Differential Revision: https://reviews.llvm.org/D28802
llvm-svn: 292224
|
| |
|
|
|
|
|
|
|
| |
instead of custom status."
It broked clang:
http://lab.llvm.org:8080/green//job/clang-stage1-cmake-RA-incremental_build/34218/consoleFull#46141505449ba4694-19c4-4d7e-bec5-911270d8a58c
llvm-svn: 292217
|
| |
|
|
|
|
|
|
|
|
|
|
| |
status.
Previously API returned custom enum values.
Patch changes it to return Error with string description.
That should help users to report errors in universal way.
Differential revision: https://reviews.llvm.org/D28684
llvm-svn: 292214
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
such problem earlier
Summary:
Emission of XRay table was occasionally disabled for Arm32, but this bug was not then detected because earlier (also by mistake) testing of XRay was occasionally disabled on 32-bit Arm targets. This patch should fix that problem and detect such problems in the future.
This patch is one of a series, see also
- https://reviews.llvm.org/D28623
Reviewers: rengolin, dberris
Reviewed By: dberris
Subscribers: llvm-commits, aemerson, rengolin, dberris, iid_iunknown
Differential Revision: https://reviews.llvm.org/D28624
llvm-svn: 292210
|
| |
|
|
|
|
|
|
| |
instructions
Simplify a vpermilvar shuffle mask based on the elements of the mask that are actually demanded.
llvm-svn: 292209
|