| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
The previous value was not sufficient for Pixel 2 phones. One would have
hoped that the newer phones are faster, but that does not seem to be the
case here.
llvm-svn: 316993
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This adds a data formatter for the implementation of forward_list in
libc++. I've refactored the existing std::list data formatter a bit to
enable more sharing of code (mainly the loop detection stuff).
Reviewers: jingham, EricWF
Subscribers: srhines, eugene, lldb-commits
Differential Revision: https://reviews.llvm.org/D35556
llvm-svn: 316992
|
| |
|
|
|
|
| |
Forgot one occurence of ArchSpec::SetTriple in mac-specific code.
llvm-svn: 316990
|
| |
|
|
|
|
|
|
|
|
|
| |
Based on similar python tool - utils/shuffle-fuzz.py - this tool extends the ability of it's previous by optionally attaching select instruction to the generated shufflevector instructions.
This was mainly developed to perform exhaustive testing of the X86 AVX512 masked shuffle instructions. But yet it can be used for various other targets.
The general design of the implementation is much modular than the original shuffle_fuzz.py tool, which makes it easier for anyone to extend it further.
Differential Revision: https://reviews.llvm.org/D38031
Change-Id: I0efc2aaa091b61a8a9552311c21cc77916a97111
llvm-svn: 316989
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes various places in clang to propagate may-alias
TBAA access descriptors during construction of lvalues, thus
eliminating the need for the LValueBaseInfo::MayAlias flag.
This is part of D38126 reworked to be a separate patch to
simplify review.
Differential Revision: https://reviews.llvm.org/D39008
llvm-svn: 316988
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
ArchSpec::SetTriple was taking a Platform as an argument, and used it to
fill in missing pieces of the specified triple. I invert the dependency
by moving this code to other classes. For this purpose, I've created
three new functions.
- HostInfo::GetAugmentedArchSpec: fills in the triple using the host
platform (this used to be implemented by passing a null platform
pointer). By putting this code in the Host module, we can provide a
way to anyone who does not have a platform instance (lldb-server) an
easy way to get Host data.
- Platform::GetAugmentedArchSpec: if you have a platform instance, you
can call this to let it fill in the triple.
- static Platform::GetAugmentedArchSpec: implements the "if platform ==
0 then use_host() else use_platform()" part.
Reviewers: zturner, jingham, clayborg
Subscribers: mgorny, javed.absar, lldb-commits
Differential Revision: https://reviews.llvm.org/D39387
llvm-svn: 316987
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The optimisation remarks for loop unrolling with an unrolled remainder looks something like:
test.c:7:18: remark: completely unrolled loop with 3 iterations [-Rpass=loop-unroll]
C[i] += A[i*N+j];
^
test.c:6:9: remark: unrolled loop by a factor of 4 with run-time trip count [-Rpass=loop-unroll]
for(int j = 0; j < N; j++)
^
This removes the first of the two messages.
Differential revision: https://reviews.llvm.org/D38725
llvm-svn: 316986
|
| |
|
|
|
|
|
|
|
| |
Unified headers will be the only way to build applications in NDK r16,
and it also works with NDK r15.
This also bumps the minimum supported android version to 16.
llvm-svn: 316985
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When there is no SECTION commands given, all sections are
technically orphans, but now we handle script orphans sections
and regular "orphans" sections for non-scripted case differently,
though we can handle them at one place.
Patch do that change.
Differential revision: https://reviews.llvm.org/D39045
llvm-svn: 316984
|
| |
|
|
|
|
|
|
| |
When collecting base pointers that need to be made available in parallel
subfunctions, use the base pointer associated with the latest
ScopArrayInfo, instead of the original one.
llvm-svn: 316983
|
| |
|
|
|
|
|
|
|
|
|
|
| |
this test was using a single makefile to build two executables. This
setup, although not supported by Makefile.rules, happened to
work in most configurations, except when building with the android ndk
r16.
Here I move the building of the second executable to a separate
makefile, which is the solution other tests use for multiple targets.
llvm-svn: 316982
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
extract subvector of vXi1 from vYi1 is poorly supported by LLVM and most of the time end with an assertion.
This patch fixes this issue by adding new patterns to the TD file.
Reviewers:
1. guyblank
2. igorb
3. zvi
4. ayman
5. craig.topper
Differential Revision: https://reviews.llvm.org/D39292
Change-Id: Ideb4d7e946c8d40cfce2920891f2d89fe64c58f8
llvm-svn: 316981
|
| |
|
|
|
|
|
| |
The address can be presented as a bitcast of baseReg.
In this case it is still trivial but OriginalValue != baseReg.
llvm-svn: 316980
|
| |
|
|
|
|
|
|
|
|
| |
Rename `Offset`, `Scale`, `Length` into `Begin`, `Step`, `End` respectively
to make naming of similar entities for Ranges and Range Checks more
consistent.
Differential Revision: https://reviews.llvm.org/D39414
llvm-svn: 316979
|
| |
|
|
|
|
|
|
|
|
| |
enabled. Use 128-bit VLX instruction when VLX is enabled.
Unfortunately, this weakens our ability to do domain fixing when AVX512DQ is not enabled, but it is consistent with our 256-bit behavior.
Maybe we should add custom handling to domain fixing to allow EVEX integer XOR/AND/OR/ANDN to switch to VEX encoded fp instructions if the high registers aren't being used?
llvm-svn: 316978
|
| |
|
|
| |
llvm-svn: 316977
|
| |
|
|
|
|
|
|
| |
As noted in the nice block comment, the previous code didn't actually handle multi-entry loops correctly, it just assumed SCEV didn't analyze such loops. Given SCEV has comments to the contrary, that seems a bit suspect. More importantly, the pass actually requires loopsimplify form which ensures a loop-preheader is available. Remove the excessive generaility and shorten the code greatly.
Note that we do successfully analyze many multi-entry loops, but we do so by converting them to single entry loops. See the added test case.
llvm-svn: 316976
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pass control flow to successors"
This patch fixes the miscompile that happens when PRE hoists loads across guards and
other instructions that don't always pass control flow to their successors. PRE is now prohibited
to hoist across such instructions because there is no guarantee that the load standing after such
instruction is still valid before such instruction. For example, a load from under a guard may be
invalid before the guard in the following case:
int array[LEN];
...
guard(0 <= index && index < LEN);
use(array[index]);
Differential Revision: https://reviews.llvm.org/D37460
llvm-svn: 316975
|
| |
|
|
|
|
|
|
| |
Previously, the code returned early from the *function* when it couldn't find a free expansion, it should be returning from the *transform*. I don't have a test case, noticed this via inspection.
As a follow up, I'm going to revisit the logic in the extract function. I think that essentially the whole helper routine can be replaced with SCEVExpander, but I wanted to do that in a series of separate commits.
llvm-svn: 316974
|
| |
|
|
| |
llvm-svn: 316973
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`check_linker_flags` currently sets the *compiler* flags (via
`CMAKE_REQUIRED_FLAGS`), and thus implicitly relies on cmake's default
behavior of passing the compiler flags to the linker. This breaks when
cmake's build rules have been altered to not pollute the link line with
compiler flags (which can be desirable for build cleanliness). Instead,
set `CMAKE_EXE_LINKER_FLAGS` explicitly and use `CMP0056` to ensure the
linker flags are passed along. Additionally, since we're inside a
function, we can just alter the variable directly (as the alteration
will be limited to the scope of the function) rather than saving and
restoring the old value.
Differential Revision: https://reviews.llvm.org/D39431
llvm-svn: 316972
|
| |
|
|
| |
llvm-svn: 316971
|
| |
|
|
| |
llvm-svn: 316970
|
| |
|
|
| |
llvm-svn: 316969
|
| |
|
|
|
|
| |
These files shouldn't have been submitted in 316967
llvm-svn: 316968
|
| |
|
|
|
|
|
|
| |
Issue found by llvm-isel-fuzzer on OSS fuzz, https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3725
If anyone actually cares about > 64 bit arithmetic, there's a lot more to do in this area. There's a bunch of obviously wrong code in the same function. I don't have the time to fix all of them and am just using this to understand what the workflow for fixing fuzzer cases might look like.
llvm-svn: 316967
|
| |
|
|
|
|
| |
rdar://35172419
llvm-svn: 316966
|
| |
|
|
|
|
|
|
|
|
|
|
| |
name the same namespace.
They might have different visibility, and thus discarding all but one of them
can result in rejecting valid code. Also fix name lookup to cope with multiple
using-directives being found that denote the same namespace, where some are not
visible -- don't cache an "already visited" state for a using-directive that we
didn't visit because it was hidden.
llvm-svn: 316965
|
| |
|
|
| |
llvm-svn: 316964
|
| |
|
|
|
|
|
|
| |
BugReporterVisitor
Differential Revision: https://reviews.llvm.org/D37935
llvm-svn: 316963
|
| |
|
|
|
|
| |
We don't need to extend/truncate the Known structure before calling computeKnownBits - it will reset at the start of the function.
llvm-svn: 316962
|
| |
|
|
|
|
|
|
| |
All SHT_NOTE sections should have minimum alignment 4.
Differential Revision: https://reviews.llvm.org/D38907
llvm-svn: 316961
|
| |
|
|
| |
llvm-svn: 316960
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D39433
llvm-svn: 316959
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
check_cxx_compiler_flag doesn't seem to try to link a program, so
the existing code doesn't correctly detect the availability of a given
linker. This patch uses check_cxx_source_compiles instead.
I confirmed that cmake now reports this error
Host compiler does not support '-fuse-ld=foo'
for -DLLVM_USE_LINKER=foo.
Differential Revision: https://reviews.llvm.org/D39274
llvm-svn: 316958
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
InferAddressSpaces assumes the pointee type of addrspacecast
is the same as the operand, which is not always true and causes
invalid IR.
This bug cause build failure in HCC.
This patch fixes that.
Differential Revision: https://reviews.llvm.org/D39432
llvm-svn: 316957
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix linker not being correctly detected when a custom one is specified
through LLVM_USE_LINKER CMake variable.
In particular,
cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_USE_LINKER=gold ../llvm
resulted into
Linker detection: GNU ld
instead of
Linker detection: GNU Gold
due to the construction not accounting for such variable. It led to the general
confusion and prevented setting linker-specific flags inside functions defined
in AddLLVM.cmake.
Thanks Oleksii Vilchanskyi for the patch!
llvm-svn: 316956
|
| |
|
|
| |
llvm-svn: 316955
|
| |
|
|
| |
llvm-svn: 316954
|
| |
|
|
|
|
|
|
| |
It's not guaranteed. There's a bug open to sort them in predecessor
order, but it won't happen anytime soon. In the meanwhile, passes
will have to do an O(#preds) scan. Such is life.
llvm-svn: 316953
|
| |
|
|
|
|
|
|
|
|
| |
Revert r316478.
A test case has failed.
Will recommit this change once we find and fix the failure.
This reverts commit 7c330fabaedaba3d02c58bc3cc1198896c895f34.
llvm-svn: 316952
|
| |
|
|
|
|
| |
unique_copy. No functional change to libc++; this is all test infastructure
llvm-svn: 316951
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
intrinsic. (NFC)
Summary:
For reference, see: http://lists.llvm.org/pipermail/llvm-dev/2017-August/116589.html
This patch fleshes out the instruction class hierarchy with respect to atomic and
non-atomic memory intrinsics. With this change, the relevant part of the class
hierarchy becomes:
IntrinsicInst
-> MemIntrinsicBase (methods-only class)
-> MemIntrinsic (non-atomic intrinsics)
-> MemSetInst
-> MemTransferInst
-> MemCpyInst
-> MemMoveInst
-> AtomicMemIntrinsic (atomic intrinsics)
-> AtomicMemSetInst
-> AtomicMemTransferInst
-> AtomicMemCpyInst
-> AtomicMemMoveInst
-> AnyMemIntrinsic (both atomicities)
-> AnyMemSetInst
-> AnyMemTransferInst
-> AnyMemCpyInst
-> AnyMemMoveInst
This involves some class renaming:
ElementUnorderedAtomicMemCpyInst -> AtomicMemCpyInst
ElementUnorderedAtomicMemMoveInst -> AtomicMemMoveInst
ElementUnorderedAtomicMemSetInst -> AtomicMemSetInst
A script for doing this renaming in downstream trees is included below.
An example of where the Any* classes should be used in LLVM is when reasoning
about the effects of an instruction (ex: aliasing).
---
Script for renaming AtomicMem* classes:
PREFIXES="[<,([:space:]]"
CLASSES="MemIntrinsic|MemTransferInst|MemSetInst|MemMoveInst|MemCpyInst"
SUFFIXES="[;)>,[:space:]]"
REGEX="(${PREFIXES})ElementUnorderedAtomic(${CLASSES})(${SUFFIXES})"
REGEX2="visitElementUnorderedAtomic(${CLASSES})"
FILES=$( grep -E "(${REGEX}|${REGEX2})" -r . | tr ':' ' ' | awk '{print $1}' | sort | uniq )
SED_SCRIPT="s~${REGEX}~\1Atomic\2\3~g"
SED_SCRIPT2="s~${REGEX2}~visitAtomic\1~g"
for f in $FILES; do
echo "Processing: $f"
sed -i ".bak" -E "${SED_SCRIPT};${SED_SCRIPT2};${EA_SED_SCRIPT};${EA_SED_SCRIPT2}" $f
done
Reviewers: sanjoy, deadalnix, apilipenko, anna, skatkov, mkazantsev
Reviewed By: sanjoy
Subscribers: hfinkel, jholewinski, arsenm, sdardis, nhaehnle, JDevlieghere, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D38419
llvm-svn: 316950
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This fixes failure in Transforms/GVNHoist/hoist.ll uncovered by D39245.
Reviewers: hiraditya, spop, dberlin
Reviewed By: dberlin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39410
llvm-svn: 316949
|
| |
|
|
|
|
|
|
|
|
|
| |
diffs.txt
Storing diffs.txt is now redundant, as we simply dump the CmpRuns output
to stdout (it is saved in CI and tends to be small).
Not generating those files enables us to remove empty folders, which
confuse git, as it would not add them with reference results.
llvm-svn: 316948
|
| |
|
|
| |
llvm-svn: 316947
|
| |
|
|
|
|
| |
These cases will be addressed in a future update to D39126.
llvm-svn: 316946
|
| |
|
|
|
|
| |
demandedelts support
llvm-svn: 316945
|
| |
|
|
| |
llvm-svn: 316944
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fixes https://reviews.llvm.org/D39072
Reviewers: cryptoad
Reviewed By: cryptoad
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D39427
llvm-svn: 316943
|