| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: procmaps OpenBSD specifics
Patch by David CARLIER
Reviewers: krytarowski, vitalybuka
Reviewed By: vitalybuka
Subscribers: mgorny, emaste, kubamracek, fedor.sergeev, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D44050
llvm-svn: 327677
|
|
|
|
|
|
|
|
| |
pipes/units
Try to demonstrate the scheduling from fpu0/fpu1 pipes to the valu0/vimul/fpa or valu1/stc/fpm functional units
llvm-svn: 327676
|
|
|
|
|
|
|
|
|
|
|
| |
There was some code that tried to calculate the number of 4-byte
words required to hold N bits, but it was instead computing the
number of bytes required to hold N bits. This was leading to
extraneous data being output into the hash table, which would
cause certain operations in DIA (the Microsoft PDB reader) to
fail.
llvm-svn: 327675
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Ripped off OpenBSD specific from the common Linux implementation
Patch by David Carlier
Reviewers: krytarowski, vitalybuka
Reviewed By: vitalybuka
Subscribers: emaste, srhines, kubamracek, fedor.sergeev, llvm-commits, #sanitizers
Differential Revision: https://reviews.llvm.org/D44036
llvm-svn: 327674
|
|
|
|
|
|
|
| |
Patch by Yury Delendik
Differential Revision: https://reviews.llvm.org/D44448
llvm-svn: 327673
|
|
|
|
|
|
|
|
| |
NFC.
Differential Revision: https://reviews.llvm.org/D43151
llvm-svn: 327672
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the loop body contains conditions of the form IndVar < #constant, we
can remove the checks by peeling off #constant iterations.
This improves codegen for PR34364.
Reviewers: mkuper, mkazantsev, efriedma
Reviewed By: mkazantsev
Differential Revision: https://reviews.llvm.org/D43876
llvm-svn: 327671
|
|
|
|
|
|
|
|
|
| |
for lexical scopes"
This is safe to land now that we don't copy FunctionInfo when rehashing
the DenseMap.
llvm-svn: 327670
|
|
|
|
| |
llvm-svn: 327669
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In COFF, duplicate string literals are merged by placing them in a
comdat whose leader symbol name contains a specific prefix followed
by the hash and partial contents of the string literal. This gives
us an easy way to identify sections containing string literals in
the linker: check for leader symbol names with the given prefix.
Any sections that are identified in this way as containing string
literals may be tail merged. We do so using the StringTableBuilder
class, which is also used to tail merge string literals in the ELF
linker. Tail merging is enabled only if ICF is enabled, as this
provides a signal as to whether the user cares about binary size.
Differential Revision: https://reviews.llvm.org/D44504
llvm-svn: 327668
|
|
|
|
|
|
|
|
|
|
| |
This makes the design a little more similar to the ELF linker and
should allow for features such as ARM range extension thunks to be
implemented more easily.
Differential Revision: https://reviews.llvm.org/D44501
llvm-svn: 327667
|
|
|
|
| |
llvm-svn: 327666
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were unnecessarily copying a bunch of these FunctionInfo objects
around when rehashing the DenseMap.
Furthermore, r327620 introduced pointers referring to objects owned by
FunctionInfo, and the default copy ctor did the wrong thing in this
case, leading to use-after-free when the DenseMap gets rehashed.
I will rebase r327620 on this next and recommit it.
llvm-svn: 327665
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
must execute
It is common to have conditional exits within a loop which are known not to be taken on some iterations, but not necessarily all. This patches extends our reasoning around guaranteed to execute (used when establishing whether it's safe to dereference a location from the preheader) to handle the case where an exit is known not to be taken on the first iteration and the instruction of interest *is* known to be taken on the first iteration.
This case comes up in two major ways:
* If we have a range check which we've been unable to eliminate, we frequently know that it doesn't fail on the first iteration.
* Pass ordering. We may have a check which will be eliminated through some sequence of other passes, but depending on the exact pass sequence we might never actually do so or we might miss other optimizations from passes run before the check is finally eliminated.
The initial version (here) is implemented via InstSimplify. At the moment, it catches a few cases, but misses a lot too. I added test cases for missing cases in InstSimplify which I'll follow up on separately. Longer term, we should probably wire SCEV through to here to get much smarter loop aware simplification of the first iteration predicate.
Differential Revision: https://reviews.llvm.org/D44287
llvm-svn: 327664
|
|
|
|
|
|
| |
Fix typo.
llvm-svn: 327663
|
|
|
|
|
|
| |
Add special case for rotate right.
llvm-svn: 327662
|
|
|
|
|
|
| |
Increase the number of cheap as move cases of register reset.
llvm-svn: 327661
|
|
|
|
|
|
|
|
| |
in isAddSubOrSubAdd when recognizing subadd
The FADD part of the addsub/subadd pattern can have its operands commuted, but when checking for fsubadd we were using the fadd as reference and commuting the fsub node.
llvm-svn: 327660
|
|
|
|
|
|
| |
The code that creates fmsubadd from shuffle vector has some code to allow commuting the operands of the fadd node. This code was originally created when we only recognized fmaddsub. When fmsubadd support was added this code was not updated and is now commuting the fsub operands instead.
llvm-svn: 327659
|
|
|
|
|
|
|
| |
I should've deleted this in r320768 but accidentally just deleted its
contents instead.
llvm-svn: 327658
|
|
|
|
|
|
|
|
|
|
| |
for lexical scopes"
It is causing crashes when compiling Chrome in debug mode.
I'll try to debug it in a second.
llvm-svn: 327657
|
|
|
|
|
|
| |
This is just to check that I have commit access privilege.
llvm-svn: 327656
|
|
|
|
|
|
|
|
| |
If we've already established an invariant scope with an earlier generation, we don't want to hide it in the scoped hash table with one with a later generation. I noticed this when working on the invariant-load handling, but it also applies to the invariant.start case as well.
Without this change, my previous patch for invariant-load regresses some cases, so I'm pushing this without waiting for review. This is why you don't make last minute tweaks to patches to catch "obvious cases" after it's already been reviewed. Bad Philip!
llvm-svn: 327655
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the variable is captured by value and the corresponding parameter in
the outlined function escapes its declaration context, this parameter
must be globalized. To globalize it we need to get the address of the
original parameter, load the value, store it to the global address and
use this global address instead of the original.
Patch improves globalization for parallel|teams regions + functions in
declare target regions.
llvm-svn: 327654
|
|
|
|
| |
llvm-svn: 327653
|
|
|
|
| |
llvm-svn: 327652
|
|
|
|
|
|
|
|
|
|
| |
PR35402 triggered this case. It bswap and stores a 48bit value, current STBRX optimization transforms it into STBRX. Unfortunately 48bit is not a simple MVT, there is no PPC instruction to support it, and it can't be automatically expanded by llvm, so caused a crash.
This patch detects the non-simple MVT and returns early.
Differential Revision: https://reviews.llvm.org/D44500
llvm-svn: 327651
|
|
|
|
| |
llvm-svn: 327650
|
|
|
|
|
|
| |
Rather than enumerating all specific types, for the DAG combine we can just use TLI::isTypeLegal and an SSE3 check. For the BUILD_VECTOR version we already know the type is legal so we just need to check SSE3.
llvm-svn: 327649
|
|
|
|
| |
llvm-svn: 327648
|
|
|
|
|
|
|
|
|
| |
It previously only worked when the key and value types were
both 4 byte integers. We now have a use case for a non trivial
value type, so we need to extend it to support arbitrary value
types, which means templatizing it.
llvm-svn: 327647
|
|
|
|
|
|
|
|
|
|
| |
This is a follow up to https://reviews.llvm.org/D43716 which rewrites the invariant load handling using the new infrastructure. It's slightly more powerful, but only in somewhat minor ways for the moment. It's not clear that DSE of stores to invariant locations is actually interesting since why would your IR have such a construct to start with?
Note: The submitted version is slightly different than the reviewed one. I realized the scope could start for an invariant load which was proven redundant and removed. Added a test case to illustrate that as well.
Differential Revision: https://reviews.llvm.org/D44497
llvm-svn: 327646
|
|
|
|
| |
llvm-svn: 327645
|
|
|
|
| |
llvm-svn: 327644
|
|
|
|
| |
llvm-svn: 327643
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This pattern came up in PR36682 / D44390
https://bugs.llvm.org/show_bug.cgi?id=36682
https://reviews.llvm.org/D44390
https://godbolt.org/g/oKvT5H
See also D44421, D44424
Reviewers: spatel, majnemer, efriedma, arsenm
Reviewed By: spatel
Subscribers: wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D44425
llvm-svn: 327642
|
|
|
|
|
|
| |
Preparation for D44425.
llvm-svn: 327641
|
|
|
|
|
|
|
|
| |
Now both method DispatchUnit::checkRAT() and DispatchUnit::canDispatch take as
input an Instruction refrence instead of an instruction descriptor.
This was requested by Simon in D44488 to simplify the diff.
llvm-svn: 327640
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Allow the runtime to use the existing shared memory statically allocated slots.
When a variable is globalized, the underlying memory can be either shared or global memory (both have block-wide visibility). In this case, we allow that the storage to use a limited amount of shared memory that has been statically allocated already. Only if shared memory doesn't prove to be enough do we then invoke malloc() to create a new global memory slot.
Reviewers: ABataev, carlo.bertolli, grokos, caomhin
Reviewed By: grokos
Subscribers: guansong, openmp-commits
Differential Revision: https://reviews.llvm.org/D44486
llvm-svn: 327639
|
|
|
|
|
|
|
|
|
|
| |
This patch addresses some additional cases where the compiler crashes upon
encountering vector GEPs. This should fix PR36116.
Differential Revision: https://reviews.llvm.org/D44219
Reference: https://bugs.llvm.org/show_bug.cgi?id=36116
llvm-svn: 327638
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: To save on calls to malloc, this patch enables the re-use of pre-allocated global memory slots.
Reviewers: ABataev, grokos, carlo.bertolli, caomhin
Reviewed By: grokos
Subscribers: guansong, openmp-commits
Differential Revision: https://reviews.llvm.org/D44470
llvm-svn: 327637
|
|
|
|
|
|
|
|
| |
Added initial codegen for device side of declarations inside `omp
declare target` construct + codegen for implicit `declare target`
functions, which are used in the target regions.
llvm-svn: 327636
|
|
|
|
|
|
|
|
|
| |
This patch adds new load/store instructions for integer scalar types
which can be used for X-Form when fed by add with an @tls relocation.
Differential Revision: https://reviews.llvm.org/D43315
llvm-svn: 327635
|
|
|
|
| |
llvm-svn: 327634
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test started failing after r327625. The cause seems difference in the
treatment of relative --stdin paths between MacOS (debugserver?) and linux
(lldb-server?). Linux treats this as relative to the debuggers PWD, while MacOS
as relative to (I think) the future PWD of the launched process.
This fixes the issue by using absolute paths, which should work everywhere, but
we should probably unify this path handling as well. I'll ask around about what
is the expected behavior here.
llvm-svn: 327633
|
|
|
|
|
|
|
|
| |
to JALU pipes
Simplifies throughput to the issue width (1/2) instead of permitting any pipe (1/6)
llvm-svn: 327632
|
|
|
|
| |
llvm-svn: 327631
|
|
|
|
|
|
|
|
|
|
|
|
| |
scheduler classes
As discussed on D44428 and PR36726, this patch splits off WriteFMove/WriteVecMove, WriteFLoad/WriteVecLoad and WriteFStore/WriteVecStore scheduler classes to permit vectors to be handled separately from gpr/scalar types.
I've minimised the diff here by only moving various basic SSE/AVX vector instructions across - we can fix the rest when called for. This does fix the MOVDQA vs MOVAPS/MOVAPD discrepancies mentioned on D44428.
Differential Revision: https://reviews.llvm.org/D44471
llvm-svn: 327630
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously, the matcher matches a function call/ref multiple times, one
for each decl ancestor. This might cause problems. For example, in the following
case, `func()` would be matched once (with namespace context) before using decl is
seen and once after using decl is seeing, which would result in different conflicting
replacements as the first match would replace `func` with "ns::func" as it doesn't
know about the using decl.
```
namespace x {
namespace {
using ::ns::func;
void f() { func(); }
}
}
```
Switching from `hasDescendant` matching to `hasAncestor` matching solves the
problem.
Reviewers: hokein
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D44517
llvm-svn: 327629
|
|
|
|
| |
llvm-svn: 327628
|