Simon Pilgrim [Tue, 22 Jan 2019 12:29:38 +0000 (12:29 +0000)]
[CostModel][X86] Add ICMP Predicate specific costs
First step towards PR40376, this patch adds support for getCmpSelInstrCost to use the (optional) Instruction CmpInst predicate to indicate the type of integer comparison we're performing and alter the costs accordingly.
Simon Pilgrim [Tue, 22 Jan 2019 12:17:48 +0000 (12:17 +0000)]
[X86][SSE] Add selective commutation support for insertps (PR40340)
When we are inserting 1 "inline" element, and zeroing 2 of the other elements then we can safely commute the insertps source inputs to improve memory folding.
Alex Bradbury [Tue, 22 Jan 2019 12:11:53 +0000 (12:11 +0000)]
[RISCV] Quick fix for PR40333
Avoid the infinite loop caused by the target DAG combine converting ANYEXT to
SIGNEXT and the target-independent DAG combine logic converting back to
ANYEXT. Do this by not adding the new node to the worklist.
Committing directly as this definitely doesn't make the problem any worse, and
I intend to follow-up with a patch that avoids this custom combiner logic
altogether and just lowers the i32 operations to a target-specific
SelectionDAG node. This should be easier to reason about and improve codegen
quality in some cases (though may miss out on some later DAG combines).
Chandler Carruth [Tue, 22 Jan 2019 10:29:58 +0000 (10:29 +0000)]
Revert r351778: IR: Add fp operations to atomicrmw
This broke the RISCV build, and even with that fixed, one of the RISCV
tests behaves surprisingly differently with asserts than without,
leaving there no clear test pattern to use. Generally it seems bad for
hte IR to differ substantially due to asserts (as in, an alloca is used
with asserts that isn't needed without!) and nothing I did simply would
fix it so I'm reverting back to green.
This also required reverting the RISCV build fix in r351782.
James Henderson [Tue, 22 Jan 2019 09:35:35 +0000 (09:35 +0000)]
[llvm-readelf]Revert --dyn-symbols behaviour to make it GNU compatible, and add new --hash-symbols switch for old behaviour
In r287786, the behaviour of --dyn-symbols in llvm-readelf (but not
llvm-readobj) was changed to print the dynamic symbols as derived from
the hash table, rather than to print the dynamic symbol table contents
directly. The original change was initially submitted without review,
and some comments were made on the commit mailing list implying that the
new behavious is GNU compatible. I argue that it is not:
1) It does not include a null symbol.
2) It prints the symbols based on an order derived from the hash
table.
3) It prints an extra column indicating which bucket it came from.
This could break parsers that expect a fixed number of columns,
with the first column being the symbol index.
4) If the input happens to have both .hash and .gnu.hash section, it
prints interpretations of them both, resulting in most symbols
being printed twice.
5) There is no way of just printing the raw dynamic symbol table,
because --symbols also prints the static symbol table.
This patch reverts the --dyn-symbols behaviour back to its old behaviour
of just printing the contents of the dynamic symbol table, similar to
what is printed by --symbols. As the hashed interpretation is still
desirable to validate the hash table, it puts it under a new switch
"--hash-symbols". This is a no-op on all output forms except for GNU
output style for ELF. If there is no hash table, it does nothing,
unlike the previous behaviour which printed the raw dynamic symbol
table, since the raw dynsym is available under --dyn-symbols.
The yaml input for the test is based on that in
test/tools/llvm-readobj/demangle.test, but stripped down to the bare
minimum to provide a valid dynamic symbol.
Note: some LLD tests needed updating. I will commit a separate patch for
those.
Eli Friedman [Tue, 22 Jan 2019 01:51:37 +0000 (01:51 +0000)]
[ARM] Combine ands+lsls to lsls+lsrs for Thumb1.
This patch may seem familiar... but my previous patch handled the
equivalent lsls+and, not this case. Usually instcombine puts the
"and" after the shift, so this case doesn't come up. However, if the
shift comes out of a GEP, it won't get canonicalized by instcombine,
and DAGCombine doesn't have an equivalent transform.
This also modifies isDesirableToCommuteWithShift to suppress DAGCombine
transforms which would make the overall code worse.
I'm not really happy adding a bunch of code to handle this, but it would
probably be tricky to substantially improve the behavior of DAGCombine
here.
Philip Reames [Tue, 22 Jan 2019 01:34:33 +0000 (01:34 +0000)]
[CVP] Use LVI to constant fold deopt operands
Deopt operands are generally intended to record information about a site in code with minimal perturbation of the surrounding code. Idiomatically, they also tend to appear down rare paths. Putting these together, we have an obvious case for extending CVP w/deopt operand constant folding. Arguably, we should be doing this for all operands on all instructions, but that's definitely a much larger and risky change.
Eli Friedman [Tue, 22 Jan 2019 00:42:20 +0000 (00:42 +0000)]
[LangRef] Clarify semantics of volatile operations.
Specifically, clarify the following:
1. Volatile load and store may access addresses that are not memory.
2. Volatile load and store do not modify arbitrary memory.
3. Volatile load and store do not trap.
Prompted by recent volatile discussion on llvmdev.
Currently, there's sort of a split in the source code about whether
volatile operations are allowed to trap; this resolves that dispute in
favor of not allowing them to trap.
JF Bastien [Mon, 21 Jan 2019 23:53:52 +0000 (23:53 +0000)]
Document toolchain update policy
Summary:
Capture the current agreed-upon toolchain update policy based on the following
discussions:
- LLVM dev meeting 2018 BoF "Migrating to C++14, and beyond!"
llvm.org/devmtg/2018-10/talk-abstracts.html#bof3
- A Short Policy Proposal Regarding Host Compilers
lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html
- Using C++14 code in LLVM (2018)
lists.llvm.org/pipermail/llvm-dev/2018-May/123182.html
- Using C++14 code in LLVM (2017)
lists.llvm.org/pipermail/llvm-dev/2017-October/118673.html
- Using C++14 code in LLVM (2016)
lists.llvm.org/pipermail/llvm-dev/2016-October/105483.html
- Document and Enforce new Host Compiler Policy
llvm.org/D47073
- Require GCC 5.1 and LLVM 3.5 at a minimum
llvm.org/D46723
Craig Topper [Mon, 21 Jan 2019 20:02:28 +0000 (20:02 +0000)]
[X86] Change avx512 COMPRESS and EXPAND lowering to use a single masked node instead of expand/compress+select.
Summary:
For compress, a select node doesn't semantically reflect the behavior of the instruction. The mask would have holes in it, but the resulting write is to contiguous elements at the bottom of the vector.
Furthermore, as far as the compressing and expanding is concerned the behavior is depended on the mask. You can't just have an expand/compress node that only reads the input vector. That node would have no meaning by itself.
This all only works because we pattern match the compress/expand+select back to the instruction. But conceivably an optimization of the select could break the pattern and leave something meaningless.
This patch modifies the expand and compress node to take the mask and passthru as additional inputs and gets rid of the select all together.
[AMDGPU] Fixed hazard recognizer to walk predecessors
Fixes two problems with GCNHazardRecognizer:
1. It only scans up to 5 instructions emitted earlier.
2. It does not take control flow into account. An earlier instruction
from the previous basic block is not necessarily a predecessor.
At the same time a real predecessor block is not scanned.
The patch provides a way to distinguish between scheduler and
hazard recognizer mode. It is OK to work with emitted instructions
in the scheduler because we do not really know what will be emitted
later and its order. However, when pass works as a hazard recognizer
the schedule is already finalized, and we have full access to the
instructions for the whole function, so we can properly traverse
predecessors and their instructions.
Nico Weber [Mon, 21 Jan 2019 18:59:11 +0000 (18:59 +0000)]
gn build: Stop passing -DLLVM_LIBXML2_ENABLED to some targets
This is a remnant from before the gn build had a working config.h.
Defining LLVM_LIBXML2_ENABLED only for targets that depend on build/libs/xml is
nice in that only some of the codebase needs to be rebuilt when
llvm_enable_libxml2 changes -- but config.h already defines it and defining it
there and then redundantly a second time for some targets is worse than having
it just in config.h.
Simon Pilgrim [Mon, 21 Jan 2019 18:04:25 +0000 (18:04 +0000)]
[X86][BtVer2] Update latency of mmx horizontal operations
D56777 added +1cy local forwarding penalty for horizontal operations, but this penalty only affects sse2/xmm variants, the mmx variants don't suffer the penalty.
Sanjay Patel [Mon, 21 Jan 2019 17:46:35 +0000 (17:46 +0000)]
[AArch64] add more tests for buildvec to shuffle transform; NFC
These are copied from the sibling x86 file. I'm not sure which
of the current outputs (if any) is considered optimal, but
someone more familiar with AArch may want to take a look.
Sanjay Patel [Mon, 21 Jan 2019 17:30:14 +0000 (17:30 +0000)]
[DAGCombiner] fix crash when converting build vector to shuffle
The regression test is reduced from the example shown in D56281.
This does raise a question as noted in the test file: do we want
to handle this pattern? I don't have a motivating example for
that on x86 yet, but it seems like we could have that pattern
there too, so we could avoid the back-and-forth using a shuffle.
Andrea Di Biagio [Mon, 21 Jan 2019 12:04:10 +0000 (12:04 +0000)]
[X86][BtVer2] Update the WriteLoad latency.
r327630 introduced new write definitions for float/vector loads.
Before that revision, WriteLoad was used by both integer/float (scalar/vector)
load. So, WriteLoad had to conservatively declare a latency to 5cy. That is
because the load-to-use latency for float/vector load is 5cy.
Now that we have dedicated writes for float/vector loads, there is no reason why
we should keep the latency of WriteLoad to 5cy. At the moment, WriteLoad is only
used by scalar integer loads only; we can assume an optimstic 3cy latency for
them.
This patch changes that latency from 5cy to 3cy, and regenerates the affected
scheduling/mca tests.
Chandler Carruth [Mon, 21 Jan 2019 09:52:34 +0000 (09:52 +0000)]
Fix typos throughout the license files that somehow I and my reviewers
all missed!
Thanks to Alex Bradbury for pointing this out, and the fact that I never
added the intended `legacy` anchor to the developer policy. Add that
anchor too. With hope, this will cause the links to all resolve
successfully.
This patch introduces the field `ExpressionSize` in SCEV. This field is
calculated only once on SCEV creation, and it represents the complexity of
this SCEV from arithmetical point of view (not from the point of the number
of actual different SCEV nodes that are used in the expression). Roughly
saying, it is the number of operands and operations symbols when we print this
SCEV.
A formal definition is following: if SCEV `X` has operands
`Op1`, `Op2`, ..., `OpN`,
then
Size(X) = 1 + Size(Op1) + Size(Op2) + ... + Size(OpN).
Size of SCEVConstant and SCEVUnknown is one.
Expression size may be used as a universal way to limit SCEV transformations
for huge SCEVs. Currently, we have a bunch of options that represents various
limits (such as recursion depth limit) that may not make any sense from the
point of view of a LLVM users who is not familiar with SCEV internals, and all
these different options pursue one goal. A more general rule that may
potentially allow us to get rid of this redundancy in options is "do not make
transformations with SCEVs of huge size". It can apply to all SCEV traversals
and transformations that may need to visit a SCEV node more than once, hence
they are prone to combinatorial explosions.
This patch only introduces SCEV sizes calculation as NFC, its utilization will
be introduced in follow-up patches.
Dylan McKay [Mon, 21 Jan 2019 04:32:02 +0000 (04:32 +0000)]
[AVR] Insert unconditional branch when inserting MBBs between blocks with fallthrough
This updates the AVR Select8/Select16 expansion code so that, when
inserting the two basic blocks for true and false conditions, any
existing fallthrough on the previous block is preserved.
Prior to this patch, if the block before the Select pseudo fell through
to the subsequent block, two new basic blocks would be inserted at the
prior fallthrough point, changing the fallthrough destination.
The predecessor or successor lists were not updated, causing the
BranchFolding pass at -O1 and above the rearrange basic blocks, causing
an infinite loop. Not to mention the unconditional fallthrough to the
true block is incorrect in of itself.
This patch modifies the Select8/16 expansion so that, if inserting true
and false basic blocks at a fallthrough point, the implicit branch is
preserved by means of an explicit, unconditional branch to the previous
fallthrough destination.
Thanks to Carl Peto for reporting this bug.
This fixes avr-rust bug https://github.com/avr-rust/rust/issues/123.
Dylan McKay [Mon, 21 Jan 2019 02:44:09 +0000 (02:44 +0000)]
[AVR] Insert unconditional branch when inserting MBBs between blocks with fallthrough
This updates the AVR Select8/Select16 expansion code so that, when
inserting the two basic blocks for true and false conditions, any
existing fallthrough on the previous block is preserved.
Prior to this patch, if the block before the Select pseudo fell through
to the subsequent block, two new basic blocks would be inserted at the
prior fallthrough point, changing the fallthrough destination.
The predecessor or successor lists were not updated, causing the
BranchFolding pass at -O1 and above the rearrange basic blocks, causing
an infinite loop. Not to mention the unconditional fallthrough to the
true block is incorrect in of itself.
This patch modifies the Select8/16 expansion so that, if inserting true
and false basic blocks at a fallthrough point, the implicit branch is
preserved by means of an explicit, unconditional branch to the previous
fallthrough destination.
Thanks to Carl Peto for reporting this bug.
This fixes avr-rust bug https://github.com/avr-rust/rust/issues/123.
Serge Guelton [Sun, 20 Jan 2019 21:19:56 +0000 (21:19 +0000)]
Replace llvm::isPodLike<...> by llvm::is_trivially_copyable<...>
As noted in https://bugs.llvm.org/show_bug.cgi?id=36651, the specialization for
isPodLike<std::pair<...>> did not match the expectation of
std::is_trivially_copyable which makes the memcpy optimization invalid.
This patch renames the llvm::isPodLike trait into llvm::is_trivially_copyable.
Unfortunately std::is_trivially_copyable is not portable across compiler / STL
versions. So a portable version is provided too.
Note that the following specialization were invalid:
std::pair<T0, T1>
llvm::Optional<T>
Tests have been added to assert that former specialization are respected by the
standard usage of llvm::is_trivially_copyable, and that when a decent version
of std::is_trivially_copyable is available, llvm::is_trivially_copyable is
compared to std::is_trivially_copyable.
As of this patch, llvm::Optional is no longer considered trivially copyable,
even if T is. This is to be fixed in a later patch, as it has impact on a
long-running bug (see r347004)
Note that GCC warns about this UB, but this got silented by https://reviews.llvm.org/D50296.
Simon Pilgrim [Sun, 20 Jan 2019 19:27:40 +0000 (19:27 +0000)]
[X86] Auto upgrade VPCOM/VPCOMU intrinsics to generic integer comparisons
This causes a couple of changes in the upgrade tests as signed/unsigned eq/ne are equivalent and we constant fold true/false codes, these changes are the same as what we already do for avx512 cmp/ucmp.
Noticed while cleaning up vector integer comparison costs for PR40376.
Matt Arsenault [Sun, 20 Jan 2019 18:40:36 +0000 (18:40 +0000)]
AMDGPU/GlobalISel: Fix some crashs in g_unmerge_values/g_merge_values
This was crashing in the predicate function assuming the value
is a vector.
Copy more of what AArch64 uses. This probably needs more refinement
later, but I don't exactly understand what it means in some cases,
particularly since any legalization for these seems to be missing.
Simon Pilgrim [Sun, 20 Jan 2019 17:36:22 +0000 (17:36 +0000)]
[X86] Auto upgrade old style VPCOM/VPCOMU intrinsics to generic integer comparisons
We were upgrading these to the new style VPCOM/VPCOMU intrinsics (which includes the condition code immediate), but we'll be getting rid of those shortly, so convert these to generics first.
This causes a couple of changes in the upgrade tests as signed/unsigned eq/ne are equivalent and we constant fold true/false codes, these changes are the same as what we already do for avx512 cmp/ucmp.
Noticed while cleaning up vector integer comparison costs for PR40376.
Simon Pilgrim [Sun, 20 Jan 2019 13:55:01 +0000 (13:55 +0000)]
[CostModel][X86] Add explicit vector select costs
Prior to SSE41 (and sometimes on AVX1), vector select has to be performed as a ((X & C)|(Y & ~C)) bit select.
Exposes a couple of issues with the min/max reduction costs (which only go down to SSE42 for some reason).
The increase pre-SSE41 selection costs also prevent a couple of tests from firing any longer, so I've either tweaked the target or added AVX tests as well to the existing SSE2 tests.
Dylan McKay [Sun, 20 Jan 2019 11:12:39 +0000 (11:12 +0000)]
[AVR] Allow AVR to be explicitly set as the default target triple
This extends the CMake cross compilation logic so that AVR can be set as
the default target triple, and thus the generic codegen tests can be
run.
This used to be possible on AVR; the CMake configuration files have
since been changed.
With this patch, 'cmake -DLLVM_DEFAULT_TARGET_TRIPLE=avr-unknown-unknown' can
be passed on the command line, making the `-mcpu` argument redundant to
'llc' and friends.
Dylan McKay [Sun, 20 Jan 2019 03:41:08 +0000 (03:41 +0000)]
[AVR] Fix codegen bug in 16-bit loads
Prior to this patch, the AVR::LDWRdPtr instruction was always lowered to
instructions of this pattern:
ld $GPR8, [PTR:XYZ]+
ld $GPR8, [PTR]+1
This has a problem; the [PTR] is incremented in-place once, but never
decremented.
Future uses of the same pointer will use the now clobbered value,
leading to the pointer being incorrect by an offset of one.
This patch modifies the expansion code of the LDWRdPtr pseudo
instruction so that the pointer variable is not silently clobbered in
future uses in the same live range.
Chandler Carruth [Sat, 19 Jan 2019 11:30:51 +0000 (11:30 +0000)]
Update structured references to the license to the new license.
Since these are intended to be short and succinct, I've used the SPDX
full name. It's human readable, but formally agreed upon and will be
part of the SPDX spec for licenses.
Chandler Carruth [Sat, 19 Jan 2019 10:56:40 +0000 (10:56 +0000)]
Update more file headers across all of the LLVM projects in the monorepo
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
Chandler Carruth [Sat, 19 Jan 2019 08:50:56 +0000 (08:50 +0000)]
Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
Chandler Carruth [Sat, 19 Jan 2019 06:36:08 +0000 (06:36 +0000)]
Convert two more files that were using Windows line endings and remove
a stray single '\r' from one file. These are the last line ending issues
I can find in the files containing parts of LLVM's file headers.
Chandler Carruth [Sat, 19 Jan 2019 06:14:24 +0000 (06:14 +0000)]
Install new LLVM license structure and new developer policy.
This installs the new developer policy and moves all of the license
files across all LLVM projects in the monorepo to the new license
structure. The remaining projects will be moved independently.
Note that I've left odd formatting and other idiosyncracies of the
legacy license structure text alone to make the diff easier to read.
Critically, note that we do not in any case *remove* the old license
notice or terms, as that remains necessary until we finish the
relicensing process.
I've updated a few license files that refer to the LLVM license to
instead simply refer generically to whatever license the LLVM project is
under, basically trying to minimize confusion.
This is really the culmination of so many people. Chris led the
community discussions, drafted the policy update and organized the
multi-year string of meeting between lawyers across the community to
figure out the strategy. Numerous lawyers at companies in the community
spent their time figuring out initial answers, and then the Foundation's
lawyer Heather Meeker has done *so* much to help refine and get us ready
here. I could keep going on, but I just want to make sure everyone
realizes what a huge community effort this has been from the begining.
Enable IPConstantPropagation to work with abstract call sites
This modification of the currently unused inter-procedural constant
propagation pass (IPConstantPropagation) shows how abstract call sites
enable optimization of callback calls alongside direct and indirect
calls. Through minimal changes, mostly dealing with the partial mapping
of callbacks, inter-procedural constant propagation was enabled for
callbacks, e.g., OpenMP runtime calls or pthreads_create.
projects / llvm / log