| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 283122
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(PR30433)
This should fix:
https://llvm.org/bugs/show_bug.cgi?id=30433
There are a couple of open questions about the codegen:
1. Should we let scalar ops be scalars and avoid vector constant loads/splats?
2. Should we have a pass to combine constants such as the inverted pair that we have here?
Differential Revision: https://reviews.llvm.org/D25165
llvm-svn: 283119
|
|
|
|
|
|
|
|
|
|
| |
If the llvm. prefix is dropped other parts of llvm don't see this as
an intrinsic. This means that the number of regular symbols depends
on the context the module is loaded into, which causes LTO to abort.
Fixes PR30509.
llvm-svn: 283117
|
|
|
|
| |
llvm-svn: 283115
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Retrying after buildbot reset.
To lex hash directives we peek ahead to find component tokens, create a
unified token, and unlex the peeked tokens so the parser does not need
to parse the tokens then. Make sure we do not to lex another hash
directive during peek operation.
This fixes PR28921.
Reviewers: rnk, loladiro
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D24839
llvm-svn: 283111
|
|
|
|
| |
llvm-svn: 283108
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Added 6 new target hooks for the vectorizer in order to filter types, handle size constraints and decide how to split chains.
Reviewers: tstellarAMD, arsenm
Subscribers: arsenm, mzolotukhin, wdng, llvm-commits, nhaehnle
Differential Revision: https://reviews.llvm.org/D24727
llvm-svn: 283099
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
library call to __aeabi_uidivmod. This is an improved implementation of
r280808, see also D24133, that got reverted because isel was stuck in a loop.
That was caused by the optimisation incorrectly triggering on i64 ints, which
shouldn't happen because there is no 64bit hwdiv support; that put isel's type
legalization and this optimisation in a loop. A native ARM compiler and testing
now shows that this is fixed.
Patch mostly by Pablo Barrio.
Differential Revision: https://reviews.llvm.org/D25077
llvm-svn: 283098
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D25110
llvm-svn: 283087
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The PPC branch-selection pass, which performs branch relaxation, needs to
account for the padding that might be introduced to satisfy block alignment
requirements. We were assuming that the first block was at offset zero (i.e.
had the alignment of the function itself), but under the ELFv2 ABI, a global
entry function prologue is added to the first block, and it is a
two-instruction sequence (i.e. eight-bytes long). If the function has 16-byte
alignment, the fact that the first block is eight bytes offset from the start
of the function is relevant to calculating where padding will be added in
between later blocks.
Unfortunately, I don't have a small test case.
llvm-svn: 283086
|
|
|
|
|
|
| |
This was accidentally copy and pasted from other Pseudos in the file.
llvm-svn: 283084
|
|
|
|
|
|
| |
I don't know for sure that we truly needs this, but its the only vector load that isn't rematerializable. Making it consistent allows it to not be a special case in the td files.
llvm-svn: 283083
|
|
|
|
| |
llvm-svn: 283080
|
|
|
|
|
|
|
| |
This was first landed in rL283058 and subsequenlty reverted since a
change this depends on (rL283057) was buggy and had to be reverted.
llvm-svn: 283079
|
|
|
|
|
|
|
|
|
|
|
| |
This change teaches getEquivalentICmp to be smarter about generating
ICMP_NE and ICMP_EQ predicates.
An earlier version of this change was landed as rL283057 which had a
use-after-free bug. This new version has a fix for that bug, and a (C++
unittests/) test case that would have triggered it rL283057.
llvm-svn: 283078
|
|
|
|
| |
llvm-svn: 283074
|
|
|
|
|
|
|
|
|
|
|
|
| |
To allow broadcast loads of a non-zero'th vector element, lowerVectorShuffleAsBroadcast can replace a load with a new load with an adjusted address, but unfortunately we weren't ensuring that the new load respected the same dependencies.
This patch adds a TokenFactor and updates all dependencies of the old load to reference the new load instead.
Bug found during internal testing.
Differential Revision: https://reviews.llvm.org/D25039
llvm-svn: 283070
|
|
|
|
|
|
| |
64-bit. This way we don't have to catch them and do nothing with them in ReplaceNodeResults.
llvm-svn: 283066
|
|
|
|
| |
llvm-svn: 283065
|
|
|
|
|
|
|
|
|
|
|
| |
They've broken the sanitizer-bootstrap bots. Reverting while I investigate.
Original commit messages:
r283057: "[ConstantRange] Make getEquivalentICmp smarter"
r283058: "[SCEV] Rely on ConstantRange instead of custom logic; NFCI"
llvm-svn: 283062
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change enables soft-float for PowerPC64, and also makes soft-float disable
all vector instruction sets for both 32-bit and 64-bit modes. This latter part
is necessary because the PPC backend canonicalizes many Altivec vector types to
floating-point types, and so soft-float breaks scalarization support for many
operations. Both for embedded targets and for operating-system kernels desiring
soft-float support, it seems reasonable that disabling hardware floating-point
also disables vector instructions (embedded targets without hardware floating
point support are unlikely to have Altivec, etc. and operating system kernels
desiring not to use floating-point registers to lower syscall cost are unlikely
to want to use vector registers either). If someone needs this to work, we'll
need to change the fact that we promote many Altivec operations to act on
v4f32. To make it possible to disable Altivec when soft-float is enabled,
hardware floating-point support needs to be expressed as a positive feature,
like the others, and not a negative feature, because target features cannot
have dependencies on the disabling of some other feature. So +soft-float has
now become -hard-float.
Fixes PR26970.
llvm-svn: 283060
|
|
|
|
|
|
|
| |
ICmpInst::makeConstantRange does exactly the same thing as
ConstantRange::makeExactICmpRegion.
llvm-svn: 283059
|
|
|
|
| |
llvm-svn: 283058
|
|
|
|
|
|
|
| |
This change teaches getEquivalentICmp to be smarter about generating
ICMP_NE and ICMP_EQ predicates.
llvm-svn: 283057
|
|
|
|
| |
llvm-svn: 283056
|
|
|
|
| |
llvm-svn: 283050
|
|
|
|
| |
llvm-svn: 283043
|
|
|
|
| |
llvm-svn: 283041
|
|
|
|
|
|
| |
We already had support for 1-input BLEND with zero - this adds support for 2-input BLEND as well.
llvm-svn: 283040
|
|
|
|
| |
llvm-svn: 283039
|
|
|
|
|
|
|
|
| |
Now we can commute to BLENDPD/BLENDPS on SSE41+ targets if necessary, so simplify the combine matching where we can.
This required me to add a couple of scalar math movsd/moss fold patterns that hadn't been needed in the past.
llvm-svn: 283038
|
|
|
|
|
|
|
|
|
|
|
|
| |
targets
Instead of selecting between MOVSD/MOVSS and BLENDPD/BLENDPS at shuffle lowering by subtarget this will help us select the instruction based on actual commutation requirements.
We could possibly add BLENDPD/BLENDPS -> MOVSD/MOVSS commutation and MOVSD/MOVSS memory folding using a similar approach if it proves useful
I avoided adding AVX512 handling as I'm not sure when we should be making use of VBLENDPD/VBLENDPS on EVEX targets
llvm-svn: 283037
|
|
|
|
|
|
| |
This reverts commit r282992 which appears to be causing an LTO test failure.
llvm-svn: 283034
|
|
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=751631
llvm-svn: 283024
|
|
|
|
| |
llvm-svn: 283021
|
|
|
|
|
|
|
|
| |
-Remove OptForSize. Not all of the backend follows the same rules for creating broadcasts and there is no conflicting pattern.
-Don't stop selecting VEX VMOVDDUP when AVX512 is supported. We need VLX for EVEX VMOVDDUP.
-Only use VMOVDDUP for v2i64 broadcasts if AVX2 is not supported.
llvm-svn: 283020
|
|
|
|
|
|
| |
This reverts commit r283017. Creates an infinite loop somehow.
llvm-svn: 283019
|
|
|
|
| |
llvm-svn: 283018
|
|
|
|
| |
llvm-svn: 283017
|
|
|
|
| |
llvm-svn: 283016
|
|
|
|
| |
llvm-svn: 283015
|
|
|
|
| |
llvm-svn: 283013
|
|
|
|
| |
llvm-svn: 283012
|
|
|
|
|
|
| |
This reverts commit r283009. Bots are broken.
llvm-svn: 283011
|
|
|
|
| |
llvm-svn: 283009
|
|
|
|
| |
llvm-svn: 283008
|
|
|
|
| |
llvm-svn: 283007
|
|
|
|
| |
llvm-svn: 283005
|
|
|
|
| |
llvm-svn: 283004
|
|
|
|
|
|
|
| |
This reverts commit r282999.
Tests are not passing: http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules/builds/20038
llvm-svn: 283003
|