David Blaikie [Wed, 18 Jul 2018 18:04:42 +0000 (18:04 +0000)]
[DebugInfo] Dwarfv5: Avoid unnecessary base_address specifiers in rnglists
Since DWARFv5 rnglists are self descriptive and have distinct encodings
for base-relative (offset_pair) and absolute (start_length) entries,
there's no need to use a base address specifier when describing a lone
address range in a section.
Use that, and improve the test coverage a bit here to include cases like
this and others.
Nirav Dave [Wed, 18 Jul 2018 18:01:03 +0000 (18:01 +0000)]
[ScheduleDAG] Fix unfolding of SUnits to already existent nodes.
Summary:
If unfolding an SUnit results in both load or the operation using it which
already exist in the DAG, abort the unfold if they are already scheduled.
If not, make sure we don't add duplicate dependencies.
Teresa Johnson [Wed, 18 Jul 2018 17:10:17 +0000 (17:10 +0000)]
[docs] Update GoldPlugin documentation
Summary:
Updated and reorganized. Made the following additions:
1) How to see if ld.gold is installed, and whether it is the current
default.
2) How to install ld.gold as the default or alternatively use
-fuse-ld=gold.
3) Move the part about installing the newly built ld-new as the default
to the prior section and how to use --enable-gold=default to do it
automatically on install.
4) Add a note about ld.bfd supporting plugins but indicate that it is
not tested by the LLVM project and gold is the recommended linker for
use with the gold plugin.
[x86/SLH] Add the design document for Speculative Load Hardening,
a Spectre v1 mitigation.
This was initially posted w/ the patch implementing this, got some basic
review there. Also, it is generated from a the Google doc that I shared
as part of the Speculative Load Hardening RFC and which has seen pretty
widespread review at this point.
However, as the patches are landing in LLVM, I wanted to land the docs
as well. But it seemed like a bad idea to have them in the same commit
in case of reverts or other things. So the docs are split out here.
Thanks for all the review so far, and further review and improvements to
the documentation here welcome. Please feel free to keep hammering on
the code review or Google document.
Note that this is a markdown document which Sphinx doesn't yet process.
But we can add support for that after and this should get picked up
(and I'm preparing patches for that). Also, this gets the document
itself into a nice shared place where we can iterate on it.
Tim Northover [Wed, 18 Jul 2018 12:36:25 +0000 (12:36 +0000)]
ARM: deduplicate hard-float detection code. NFC.
ARMSubtarget had a copy/pasted block to determine whether the target was
hard-float, but it just delegated to triple features anyway so it's better at
the TargetMachine level.
[AArch64][SVE] Asm: Support for unpredicated FP operations.
This patch adds support for the following unpredicated
floating-point instructions:
FADD Floating point add
FSUB Floating point subtract
FMUL Floating point multiplication
FTSMUL Floating point trigonometric starting value
FRECPS Floating point reciprocal step
FRSQRTS Floating point reciprocal square root step
The instructions have the following assembly format:
fadd z0.h, z1.h, z2.h
and have variants for 16, 32 and 64-bit FP elements.
As discussed in https://reviews.llvm.org/D49179#1158957 and later,
the IR for 'check for [no] signed truncation' pattern can be improved:
https://rise4fun.com/Alive/gBf
^ that pattern will be produced by Implicit Integer Truncation sanitizer,
https://reviews.llvm.org/D48958 https://bugs.llvm.org/show_bug.cgi?id=21530
in signed case, therefore it is probably a good idea to improve it.
The DAGCombine will reverse this transform, see
https://reviews.llvm.org/D49266
This transform is surprisingly frustrating.
This does not deal with non-splat shift amounts, or with undef shift amounts.
I've outlined what i think the solution should be:
```
// Potential handling of non-splats: for each element:
// * if both are undef, replace with constant 0.
// Because (1<<0) is OK and is 1, and ((1<<0)>>1) is also OK and is 0.
// * if both are not undef, and are different, bailout.
// * else, only one is undef, then pick the non-undef one.
```
This is a re-commit, as the original patch, committed in rL337190
was reverted in rL337344 as it broke chromium build:
https://bugs.llvm.org/show_bug.cgi?id=38204 and
https://crbug.com/864832
Proofs that the fixed folds are ok: https://rise4fun.com/Alive/VYM
Simon Pilgrim [Wed, 18 Jul 2018 10:54:13 +0000 (10:54 +0000)]
[X86][SSE] Add extra scalar fop + blend tests for commuted inputs
While working on PR38197, I noticed that we don't make use of FADD/FMUL being able to commute the inputs to support the addps+movss -> addss style combine
[AArch64][SVE] Asm: Support for UDOT/SDOT instructions.
The signed/unsigned DOT instructions perform a dot-product on
quadtuplets from two source vectors and accumulate the result in
the destination register. The instructions come in two forms:
Vector form, e.g.
sdot z0.s, z1.b, z2.b - signed dot product on four 8-bit quad-tuplets,
accumulating results in 32-bit elements.
udot z0.d, z1.h, z2.h - unsigned dot product on four 16-bit quad-tuplets,
accumulating results in 64-bit elements.
Indexed form, e.g.
sdot z0.s, z1.b, z2.b[3] - signed dot product on four 8-bit quad-tuplets
with specified quadtuplet from second
source vector, accumulating results in 32-bit
elements.
udot z0.d, z1.h, z2.h[1] - dot product on four 16-bit quad-tuplets
with specified quadtuplet from second
source vector, accumulating results in 64-bit
elements.
George Rimar [Wed, 18 Jul 2018 09:25:36 +0000 (09:25 +0000)]
[llvm-objdump] - An attempt to fix BB after r337361.
Seems r337361 is the reason of the following ARM BB failures:
http://lab.llvm.org:8011/builders/clang-cmake-armv8-quick
http://lab.llvm.org:8011/builders/clang-cmake-armv8-full/builds/4633
Reason is unclear to me, other bots are OK.
If this will not help, I'll revert r337361.
This patch adds the following predicated instructions:
UDIV Unsigned divide active elements
UDIVR Unsigned divide active elements, reverse form.
SDIV Signed divide active elements
SDIVR Signed divide active elements, reverse form.
e.g.
udiv z0.s, p0/m, z0.s, z1.s
(unsigned divide active elements in z0 by z1, store result in z0)
sdivr z0.s, p0/m, z0.s, z1.s
(signed divide active elements in z1 by z0, store result in z0)
Philip Pfaffe [Wed, 18 Jul 2018 08:53:31 +0000 (08:53 +0000)]
[CMake] Export the LLVM_LINK_LLVM_DYLIB setting
Summary:
When building out-of-tree tools, there are several macros available to
automate linking against llvm. An examples is `add_llvm_executable`, or
the clang variant of this.
These macros use the LLVM_LINK_LLVM_DYLIB option to decide whether to
link against libraries defined by setting LLVM_LINK_COMPONENTS or to
link against libLLVM instead. Currently this is problematic in
out-of-tree targets, because they cannot identify whether this option is
required or even available. If the option was enabled in LLVM's own
build, the clang libraries are built against libLLVM, so a client
linking against those must link against it too. On the other hand the
client can't just always link against it, because it might not be
available.
This is related to D44391, but that change assumed the client knew
whether they wanted the dylib or not.
Imagine we have a file with few sections, and one of them is .foo
with index N != 0.
Problem is that when llvm-objdump is given a -section=.foo parameter
it lists .foo as a section at index 0. That makes impossible to write
test cases which needs to find the index of the particular section,
while ignoring dumping of others.
says that e_shnum and/or e_shstrndx may have special values if
"the number of sections is greater than or equal to SHN_LORESERVE" or
"the section name string table section index is greater than or equal to SHN_LORESERVE (0xff00)"
Previously llvm-readobj was unable to dump such files, patch changes that.
I had to add a precompiled test case because it does not seem possible to
prepare a test using yaml2obj or llvm-mc (not clear how to make .shstrtab
to have index >= SHN_LORESERVE).
[AArch64][SVE] Asm: Support for integer MUL instructions.
This patch adds the following instructions:
MUL - multiply vectors, e.g.
mul z0.h, p0/m, z0.h, z1.h
- multiply with immediate, e.g.
mul z0.h, z0.h, #127
SMULH - signed multiply returning high half, e.g.
smulh z0.h, p0/m, z0.h, z1.h
UMULH - unsigned multiply returning high half, e.g.
umulh z0.h, p0/m, z0.h, z1.h
* Delete a no-longer-used override, and mark the other
getRegisterTypeForCallingConv() as override.
* SPE only supports i32, not i64, as the internal type, so simply remove
the type check, so that DestReg and Opc are provably always set.
[X86] Remove patterns that mix X86ISD::MOVLHPS/MOVHLPS with v2i64/v2f64 types.
The X86ISD::MOVLHPS/MOVHLPS should now only be emitted in SSE1 only. This means that the v2i64/v2f64 types would be illegal thus we don't need these patterns.
[X86] Generate v2f64 X86ISD::UNPCKL/UNPCKH instead of X86ISD::MOVLHPS/MOVHLPS for unary v2f64 {0,0} and {1,1} shuffles with SSE2.
I'm trying to restrict the MOVLHPS/MOVHLPS ISD nodes to SSE1 only. With SSE2 we can use unpcks. I believe this will allow some patterns to be cleaned up to require fewer bitcasts.
I've put in an odd isel hack to still select MOVHLPS instruction from the unpckh node to avoid changing tests and because movhlps is a shorter encoding. Ideally we'd do execution domain switching on this, but the operands are in the wrong order and are tied. We might be able to try a commute in the domain switching using custom code.
We already support domain switching for UNPCKLPD and MOVLHPS.
Introduce codegen for the Signal Processing Engine
Summary:
The Signal Processing Engine (SPE) is found on NXP/Freescale e500v1,
e500v2, and several e200 cores. This adds support targeting the e500v2,
as this is more common than the e500v1, and is in SoCs still on the
market.
This patch is very intrusive because the SPE is binary incompatible with
the traditional FPU. After discussing with others, the cleanest
solution was to make both SPE and FPU features on top of a base PowerPC
subset, so all FPU instructions are now wrapped with HasFPU predicates.
Supported by this are:
* Code generation following the SPE ABI at the LLVM IR level (calling
conventions)
* Single- and Double-precision math at the level supported by the APU.
Still to do:
* Vector operations
* SPE intrinsics
As this changes the Callee-saved register list order, one test, which
tests the precise generated code, was updated to account for the new
register order.
Bob Haarman [Wed, 18 Jul 2018 02:18:28 +0000 (02:18 +0000)]
Revert "[InstCombine] Fold 'check for [no] signed truncation' pattern"
This reverts r337190 (and a few follow-up commits), which caused the
Chromium build to fail. See
https://bugs.llvm.org/show_bug.cgi?id=38204 and
https://crbug.com/864832
CodeGen: Don't create address significance table entries for thread-local variables.
The presence of these symbols in the symbol table can cause symbol type
mismatch errors (or undefined symbol errors on emulated TLS targets)
and they can't be ICF'd anyway.
Eli Friedman [Tue, 17 Jul 2018 20:38:11 +0000 (20:38 +0000)]
[LangRef] Clarify semantics of load metadata.
We need to explicitly state what happens when an invariant promised by
load metadata is violated at runtime, since it's come up repeatedly.
It's possible we want to specify that the result of the load is poison
in some cases, rather than undefined behavior, if the constraint is
violated. That would allow preserving the metadata when the load is
hoisted, but doesn't allow propagating metadata based on control flow.
We currently do transforms based on control flow for nonnull metadata
(in PromoteMemToReg).
Add some helper functions to the demangle utility classes.
These are all methods that, while not currently used in the
Itanium demangler, are generally useful enough that it's
likely the itanium demangler could find a use for them. More
importantly, they are all necessary for the Microsoft demangler
which is up and coming in a subsequent patch. Rather than
combine these into a single monolithic patch, I think it makes
sense to commit this utility code first since it is very simple,
this way it won't detract from the substance of the MS demangler
patch.
[x86/SLH] Flesh out the data-invariant instruction table a bit based on feedback from Craig.
Summary:
The only thing he suggested that I've skipped here is the double-wide
multiply instructions. Multiply is an area I'm nervous about there being
some hidden data-dependent behavior, and it doesn't seem important for
any benchmarks I have, so skipping it and sticking with the minimal
multiply support that matches what I know is widely used in existing
crypto libraries. We can always add double-wide multiply when we have
clarity from vendors about its behavior and guarantees.
I've tried to at least cover the fundamentals here with tests, although
I've not tried to cover every width or permutation. I can add more tests
where folks think it would be helpful.
Sam Clegg [Tue, 17 Jul 2018 16:40:03 +0000 (16:40 +0000)]
[WebAssembly] Update WebAssemblyLowerEmscriptenEHSjLj to handle separate compilation
Previously we were assuming whole program compilation. Now that
separate compilation is a thing we need to update this pass.
Firstly, it can no longer assert on the existence of malloc and free.
This functions might not be in the current translation unit. If we
need them then we will generate not imports for them.
Secondly the global helper function we create should be marked as
weak since we will be generating a separate copy in each translation
unit.
Finally the names of the symbols used must be unique and fixed since
they need to agree across translation units.
[X86] Remove some standalone patterns in favor of the patterns in the MOVLPD instruction definitions.
Previously we passed 'null_frag' into the instruction definition. The multiclass is shared with MOVHPD which doesn't use null_frag. It turns out by passing X86Movsd it produces patterns equivalent to some standalone patterns.
Simon Pilgrim [Tue, 17 Jul 2018 16:13:29 +0000 (16:13 +0000)]
[llvm-mca][x86] Add LEA resource tests (PR32326)
Add llvm-mca tests demonstrating how LEA instructions are currently modelled. Once this is working on btver2 I'll copy the test file to the other target directories.
Matt Davis [Tue, 17 Jul 2018 16:11:54 +0000 (16:11 +0000)]
[llvm-mca][docs] Revert mca internals docs.
We're going to work on this in a separate review focusing more on documenting
the View and probably removing some of the less-interesting/less-useful pieces.
Andrea Di Biagio [Tue, 17 Jul 2018 16:11:37 +0000 (16:11 +0000)]
[Tablegen][PredicateExpander] Fix a bug in `expandCheckImmOperand`.
Function `expandCheckImmOperand` should always check if the input machine
instruction is passed by reference before calling method `getOperand()` on it.
Found while working on a patch that relies on `expandCheckImmOperand` to expand
a scheduling predicate.
[IPSCCP] Run Solve each time we resolved an undef in a function.
Once we resolved an undef in a function we can run Solve, which could
lead to finding a constant return value for the function, which in turn
could turn undefs into constants in other functions that call it, before
resolving undefs there.
Computationally the amount of work we are doing stays the same, just the
order we process things is slightly different and potentially there are
a few less undefs to resolve.
We are still relying on the order of functions in the IR, which means
depending on the order, we are able to resolve the optimal undef first
or not. For example, if @test1 comes before @testf, we find the constant
return value of @testf too late and we cannot use it while solving
@test1.
This on its own does not lead to more constants removed in the
test-suite, probably because currently we have to be very lucky to visit
applicable functions in the right order.
Maybe we manage to come up with a better way of resolving undefs in more
'profitable' functions first.
Simon Pilgrim [Tue, 17 Jul 2018 13:43:33 +0000 (13:43 +0000)]
[SLPVectorizer] Don't attempt horizontal reduction on pointer types (PR38191)
TTI::getMinMaxReductionCost typically can't handle pointer types - until this is changed its better to limit horizontal reduction to integer/float vector types only.
Tim Renouf [Tue, 17 Jul 2018 12:38:39 +0000 (12:38 +0000)]
More fixes for subreg join failure in RegCoalescer
Summary:
Part of the adjustCopiesBackFrom method wasn't correctly dealing with SubRange
intervals when updating.
2 changes. The first to ensure that bogus SubRange Segments aren't propagated when
encountering Segments of the form [1234r, 1234d:0) when preparing to merge value
numbers. These can be removed in this case.
The second forces a shrinkToUses call if SubRanges end on the copy index
(instead of just the parent register).
V2: Addressed review comments, plus MIR test instead of ll test
[AArch64][SVE] Asm: Support for predicated FP operations (FP immediate)
This patch completes support for the following floating point
instructions that take FP immediates:
FADD* (addition)
FSUB (subtract)
FSUBR (subtract reverse form)
FMUL* (multiplication)
FMAX* (maximum)
FMAXNM (maximum number)
FMIN (maximum)
FMINNM (maximum number)
All operations are predicated and take a FP immediate operand,
e.g.
[LLVM-C] Fix name mangling on AggressiveInstCombine
Similarly to rL336736, at least one more C API function does not
properly get declared as extern "C" due to a missing header, causing
name mangling and linking errors.
This patch fixes calls to LLVMAddAggressiveInstCombinerPass().
[LLVM-C] Add target triple normalization to the C API.
rL333307 was introduced to remove automatic target triple
normalization when calling sys::getDefaultTargetTriple(), arguing
that users of the latter already called Triple::normalize()
if necessary. However, users of the C API currently have no way of
doing target triple normalization.
This patch introduces an LLVMNormalizeTargetTriple function to
the C API which wraps Triple::normalize() and can be used on
the result of LLVMGetDefaultTargetTriple to achieve the same effect.
[AArch64][SVE] Asm: Support for SPLICE instruction.
The SPLICE instruction splices two vectors into one vector using a
predicate. It copies the active elements from the first vector, and
then fills the remaining elements with the low-numbered elements from
the second vector.
The instruction has the following form, e.g.
splice z0.b, p0, z0.b, z1.b
for 8-bit elements. It also supports 16, 32 and
64-bit elements.
This patch adds an instruction that allows extracting
a vector from a pair of vectors, given an immediate index
that describes the element position to extract from.
The instruction has the following assembly:
ext z0.b, z0.b, z1.b, #imm
Daniel Cederman [Tue, 17 Jul 2018 05:49:33 +0000 (05:49 +0000)]
[Sparc] Do not depend on icc for ta 1
The ta instruction will always trap, regardless of the value
of the integer condition codes. TRAPri is marked as using icc,
so we cannot use a pattern for TRAPri to implement ta 1, as
verify-machineinstrs can complain that icc is not defined.
Instead we implement ta 1 the same way as ta 5.
[X86] Add full set of patterns for turning ceil/floor/trunc/rint/nearbyint into rndscale with loads, broadcast, and masking.
This amounts to pretty ridiculous number of patterns. Ideally we'd canonicalize the X86ISD::VRNDSCALE earlier to reuse those patterns. I briefly looked into doing that, but some strict FP operations could still get converted to rint and nearbyint during isel. It's probably still worthwhile to look into. This patch is meant as a starting point to work from.
projects / llvm / log