| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This intrinsic represents a label with a list of associated metadata
strings. It is modelled as reading and writing inaccessible memory so
that it won't be removed as dead code. I think the intention is that the
annotation strings should appear at most once in the debug info, so I
marked it noduplicate. We are allowed to inline code with annotations as
long as we strip the annotation, but that can be done later.
Reviewers: majnemer
Subscribers: eraman, llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D36904
llvm-svn: 312569
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
handles out of range truncations of the start and accum values
Summary:
When constructing the predicate P1 in ScalarEvolution::createAddRecFromPHIWithCastsImpl() it is possible
for the PHISCEV from which the predicate is constructed to be a SCEVConstant instead of a SCEVAddRec. If
this happens, then the cast<SCEVAddRec>(PHISCEV) in the code will assert.
Such a PHISCEV is possible if either the start value or the accumulator value is a constant value
that not equal to its truncated value, and if the truncated value is zero.
This patch adds tests that demonstrate the cast<> assertion, and fixes this problem by checking
whether the PHISCEV is a constant before constructing the P1 predicate; if it is, then P1 is
equivalent to one of P2 or P3. Additionally, if we know that the start value or accumulator
value are constants then we check whether the P2 and/or P3 predicates are known false at compile
time; if either is, then we bail out of constructing the AddRec.
Reviewers: sanjoy, mkazantsev, silviu.baranga
Reviewed By: mkazantsev
Subscribers: mkazantsev, llvm-commits
Differential Revision: https://reviews.llvm.org/D37265
llvm-svn: 312568
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
It appears that a potential race between the cache client and the cache
pruner that I thought was unlikely actually happened in practice [1].
Try to avoid the race condition by opening the temporary file before
renaming it. Do this only on non-Windows platforms because we cannot
rename open files on Windows using the sys::fs::rename function.
[1] https://luci-logdog.appspot.com/v/?s=chromium%2Fbb%2Fchromium.memory%2FLinux_CFI%2F1610%2F%2B%2Frecipes%2Fsteps%2Fcompile%2F0%2Fstdout
Differential Revision: https://reviews.llvm.org/D37410
llvm-svn: 312567
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
FR32X)))) patterns
We had already disabled the pattern for SSE4.1 and SSE4.2. But it got re-enabled for AVX and AVX512.
With SSE41 we rely on a separate (v4f32 (X86vzmovl VR128)) pattern to select blendps with a xorps to create zeroess. And a separate (v4f32 (scalar_to_vector FR32X)) to select a COPY_TO_REG_CLASS to move FR32 to VR128
The same thing can happen for AVX with vblendps and those separate patterns already exist.
For AVX512, (v4f32 (X86vzmov VR128)) will select a VMOVSS instruction instead of VBLENDPS due to their not being a EVEX VBLENDPS. This is what we were getting out of the larger pattern anyway. So the larger pattern is unneeded for AVX512 too.
For SSE1-SSSE3 we can rely on (v4f32 (X86vzmov VR128)) selecting a MOVSS similar to AVX512. Again this is what the larger pattern did too.
So the only real change here is that AVX1/2 now properly outputs a VBLENDPS during isel instead of a VMOVSS to match SSE41. Most tests didn't notice because the two address instruction pass knows how to turn VMOVSS into VBLENDPS to get an independent destination register.
llvm-svn: 312564
|
| |
|
|
|
|
|
|
|
| |
- Refactor SIMemOpInfo's constructors
- Allow construction of NotAtomic SIMemOpInfo
Differential Revision: https://reviews.llvm.org/D37396
llvm-svn: 312563
|
| |
|
|
|
|
|
|
| |
If the only call in a function is a tail call, the
function isn't considered to have a call since it's a
type of return.
llvm-svn: 312561
|
| |
|
|
|
|
| |
Some of the cases show missing pattern i intend to fix shortly.
llvm-svn: 312560
|
| |
|
|
|
|
|
|
| |
more general.
Commit on behalf of Graham Yiu (gyiu@ca.ibm.com)
llvm-svn: 312547
|
| |
|
|
|
|
| |
This prepares for https://reviews.llvm.org/D33514
llvm-svn: 312544
|
| |
|
|
|
|
|
|
| |
(v4f32 (scalar_to_vector FR32X:)), (iPTR 0)))) and the same for v4f64.
We don't have this same pattern for AVX2 so I don't believe we should have it for AVX512. We also didn't have it for v16f32.
llvm-svn: 312543
|
| |
|
|
|
|
|
|
|
|
| |
- Make SIMemOpInfo a class
- Add accessor methods to SIMemOpInfo
- Move get*Info methods to SIMemOpInfo
Differential Revision: https://reviews.llvm.org/D37395
llvm-svn: 312541
|
| |
|
|
|
|
|
|
|
| |
- Rename MemOpInfo -> SIMemOpInfo
- Move SIMemOpInfo class out of SIMemoryLegalizer class
Differential Revision: https://reviews.llvm.org/D37394
llvm-svn: 312540
|
| |
|
|
| |
llvm-svn: 312537
|
| |
|
|
|
|
|
|
| |
As suggested by @niravd : https://bugs.llvm.org/show_bug.cgi?id=34421#c2
Differential Revision: https://reviews.llvm.org/D37464
llvm-svn: 312534
|
| |
|
|
| |
llvm-svn: 312531
|
| |
|
|
| |
llvm-svn: 312530
|
| |
|
|
| |
llvm-svn: 312529
|
| |
|
|
| |
llvm-svn: 312528
|
| |
|
|
| |
llvm-svn: 312527
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch adds failing gracefully when running out of memory when
allocating a buffer for decompression.
This provides a work-around for:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3224
Differential revision: https://reviews.llvm.org/D37447
llvm-svn: 312526
|
| |
|
|
|
|
|
|
| |
Use the STI member of ARMInstructionSelector instead of
TII.getSubtarget() and also make use of STI's methods instead of
checking the object format manually.
llvm-svn: 312522
|
| |
|
|
|
|
|
|
|
| |
In RWPI code, globals that are not read-only are accessed relative to
the SB register (R9). This is achieved by explicitly generating an ADD
instruction between SB and an offset that we either load from a constant
pool or movw + movt into a register.
llvm-svn: 312521
|
| |
|
|
|
|
| |
had their patterns removed.
llvm-svn: 312520
|
| |
|
|
|
|
|
|
|
|
| |
(bitwiseop Y, C2), Y -> (bitwiseop Y, (shl/shr (and X, C1), C3)) or similar.
This is possible if C1 and C2 are both powers of 2. Or if binop is 'and' then ~C2 needs to be a power of 2.
We already support this for 'or', but we should be able to support 'and' and 'xor'. This will be enhanced by D37274.
llvm-svn: 312519
|
| |
|
|
|
|
| |
enable reuse in a future patch.
llvm-svn: 312518
|
| |
|
|
|
|
|
|
|
|
| |
for sure we're going to use it and avoid an unnecessary call to m_APInt.
Instead of creating a Constant and then calling m_APInt with it (which will always return true). Just create an APInt initially, and use that for the checks in isSelect01 function. If it turns out we do need the Constant, create it from the APInt.
This is a refactor for a future patch that will do some more checks of the constant values here.
llvm-svn: 312517
|
| |
|
|
| |
llvm-svn: 312516
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
builds seem to be having trouble with it.
http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules-2/builds/11401
When trying to link lli-child-target, the linker reports missing symbols for
the 'Name' members of 'rpc::Function<OrcRPCNegotiate, FunctionIdT(std::string)>'
(base class for OrcRPCNegotiate) and 'rpc::Function<OrcRPCResponse, void()>'
(base class for OrcRPCResponse), despite there being definitions for these
immediately below the rpc::Function class template.
This looks like the same bug that bit OrcRemoteTargetClient/Server in r286920.
<rdar://problem/34249745>
llvm-svn: 312515
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If multiple conditional branches are executed based on the same comparison, we can execute multiple conditional branches based on the result of one comparison on PPC. For example,
if (a == 0) { ... }
else if (a < 0) { ... }
can be executed by one compare and two conditional branches instead of two pairs of a compare and a conditional branch.
This patch identifies a code sequence of the two pairs of a compare and a conditional branch and merge the compares if possible.
To maximize the opportunity, we do canonicalization of code sequence before merging compares.
For the above example, the input for this pass looks like:
cmplwi r3, 0
beq 0, .LBB0_3
cmpwi r3, -1
bgt 0, .LBB0_4
So, before merging two compares, we canonicalize it as
cmpwi r3, 0 ; cmplwi and cmpwi yield same result for beq
beq 0, .LBB0_3
cmpwi r3, 0 ; greather than -1 means greater or equal to 0
bge 0, .LBB0_4
The generated code should be
cmpwi r3, 0
beq 0, .LBB0_3
bge 0, .LBB0_4
Differential Revision: https://reviews.llvm.org/D37211
llvm-svn: 312514
|
| |
|
|
|
|
| |
This snippet was accidentally in the final commit, but is unused.
llvm-svn: 312513
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch introduces RemoteObjectClientLayer and RemoteObjectServerLayer,
which can be used to forward ORC object-layer operations from a JIT stack in
the client to a JIT stack (consisting only of object-layers) in the server.
This is a new way to support remote-JITing in LLVM. The previous approach
(supported by OrcRemoteTargetClient and OrcRemoteTargetServer) used a
remote-mapping memory manager that sat "beneath" the JIT stack and sent
fully-relocated binary blobs to the server. The main advantage of the new
approach is that relocatable objects can be cached on the server and re-used
(if the code that they represent hasn't changed), whereas fully-relocated blobs
can not (since the addresses they have been permanently bound to will change
from run to run).
llvm-svn: 312511
|
| |
|
|
|
|
| |
detect self-cycles of phi nodes. We also need to not ignore certain types of arguments when testing whether the phi has a backedge or was originally constant.
llvm-svn: 312510
|
| |
|
|
|
|
| |
aggregate value simplification
llvm-svn: 312509
|
| |
|
|
| |
llvm-svn: 312508
|
| |
|
|
|
|
| |
finding is done. Where we had it before, we would stop looking when we hit the original instruction, but skip it. Now we skip it and keep looking.
llvm-svn: 312507
|
| |
|
|
| |
llvm-svn: 312504
|
| |
|
|
| |
llvm-svn: 312503
|
| |
|
|
| |
llvm-svn: 312502
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
code duplication in the client, and improve error propagation.
This patch moves the OrcRemoteTarget rpc::Function declarations from
OrcRemoteTargetRPCAPI into their own namespaces under llvm::orc::remote so that
they can be used in new contexts (in particular, a remote-object-file adapter
layer that I will commit shortly).
Code duplication in OrcRemoteTargetClient (especially in loops processing the
code, rw-data and ro-data allocations) is removed by moving the loop bodies
into their own functions.
Error propagation is (slightly) improved by adding an ErrorReporter functor to
the OrcRemoteTargetClient -- Errors that can't be returned (because they occur
in destructors, or behind stable APIs that don't provide error returns) can be
sent to the ErrorReporter instead. Some methods in the Client API are also
changed to make better use of the Expected class: returning Expected<T>s rather
than returning Errors and taking T&s to store the results.
llvm-svn: 312500
|
| |
|
|
|
|
|
|
|
| |
As noted in PR11210:
https://bugs.llvm.org/show_bug.cgi?id=11210
...fixing this should allow us to eliminate x86-specific masked store intrinsics in IR.
(Although more testing will be needed to confirm that.)
llvm-svn: 312496
|
| |
|
|
|
|
|
|
|
|
| |
forwarding""
This crashes on boringSSL on PPC (will send reduced testcase)
This reverts commit r312328.
llvm-svn: 312490
|
| |
|
|
|
|
|
|
|
| |
This patch fixes regression related with
integer-bool-dwarf test.
Patch by Nikola Prica.
llvm-svn: 312489
|
| |
|
|
| |
llvm-svn: 312487
|
| |
|
|
|
|
| |
Avoid use of VPERMPS where we don't need it by instead using the variable mask version of VPERMILPS for unary shuffles.
llvm-svn: 312486
|
| |
|
|
| |
llvm-svn: 312485
|
| |
|
|
| |
llvm-svn: 312481
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
range lists.
It solves issue of wrong section index evaluating for ranges when
base address is used.
Based on David Blaikie's patch D36097.
Differential revision: https://reviews.llvm.org/D37214
llvm-svn: 312477
|
| |
|
|
|
|
| |
https://reviews.llvm.org/rL312442
llvm-svn: 312474
|
| |
|
|
| |
llvm-svn: 312473
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Improve how MaxVF is computed while taking into account that MaxVF should not be larger than the loop's trip count.
Other than saving on compile-time by pruning the possible MaxVF candidates, this patch fixes pr34438 which exposed the following flow:
1. Short trip count identified -> Don't bail out, set OptForSize:=True to avoid tail-loop and runtime checks.
2. Compute MaxVF returned 16 on a target supporting AVX512.
3. OptForSize -> choose VF:=MaxVF.
4. Bail out because TripCount = 8, VF = 16, TripCount % VF !=0 means we need a tail loop.
With this patch step 2. will choose MaxVF=8 based on TripCount.
Reviewers: Ayal, dorit, mkuper, hfinkel
Reviewed By: hfinkel
Subscribers: hfinkel, llvm-commits
Differential Revision: https://reviews.llvm.org/D37425
llvm-svn: 312472
|