Summary:
This allows target to implement custom emit of global variables if
required. See subsequent patch for a use case.
Change-Id: I9654197e3df24503104a54c41fff06845aed37fe
Reviewers: arsenm, kzhuravl
Subscribers: wdng, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61650
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363519 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Instead of encoding a high-word of 0 using a fake TargetGlobalAddress,
just use a literal target constant. This simplifies some subsequent changes.
The generated assembly is now more explicit about the kind of relocation
that is to be used.
Change-Id: I066835202d23b5941fa7a358eb4b89e9b71ab6f8
Reviewers: arsenm, rampitec
Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61491
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363516 91177308-0d34-0410-b5e6-96231b3b80d8
This is based on the example/discussion in PR37428:
https://bugs.llvm.org/show_bug.cgi?id=37428
Proper vector shift instructions don't appear until AVX2, so we may generate several
extra instructions within a loop trying to compensate for that. It's difficult to
recover from that shift expansion later than this, so use the existing TLI hook and
splat analysis to enable better codegen.
This extends CGP functionality introduced with:
rL201655
Differential Revision: https://reviews.llvm.org/D63233
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363511 91177308-0d34-0410-b5e6-96231b3b80d8
This is similar logic/motivation to the select splitting in D62969.
In D63233, the pattern changes so that we no longer have an extract_subvector of vselect,
but the operands of the select are still being concatenated.
The closest case is represented in either the first or last test diffs here - we have an
extra instruction, but we converted 3-4 ymm instructions into 4-5 xmm instructions.
I think that's the right trade-off for most AVX1 targets.
In the example based on PR37428:
https://bugs.llvm.org/show_bug.cgi?id=37428
...this makes the loop about 30% faster (tested on Haswell by compiling with -mavx).
Differential Revision: https://reviews.llvm.org/D63364
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363508 91177308-0d34-0410-b5e6-96231b3b80d8
Pull out the existing (non)lane-crossing fold into a helper lambda and use for lane-crossing unary shuffles as well.
Fixes PR34380
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363500 91177308-0d34-0410-b5e6-96231b3b80d8
This mostly happens due to SimplifyDemandedVectorElts reducing a vector to insert_subvector(undef, c1, 0)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363499 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
With Split DWARF the resulting object file (then called skeleton CU)
contains the file name of another ("DWO") file with the debug info.
This can be a problem for remote compilation, as it will contain the
name of the file on the compilation server, not on the client.
To use Split DWARF with remote compilation, one needs to either
* make sure only relative paths are used, and mirror the build directory
structure of the client on the server,
* inject the desired file name on the client directly.
Since llc already supports the latter solution, we're just copying that
over. We allow setting the actual output filename separately from the
value of the DW_AT_[GNU_]dwo_name attribute in the skeleton CU.
Fixes PR40276.
Reviewers: dblaikie, echristo, tejohnson
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D59673
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363496 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
If the nested loop is an innermost loop, prefer to a 32-byte alignment, so that
we can decrease cache misses and branch-prediction misses. Actual alignment of
the loop will depend on the hotness check and other logic in alignBlocks.
The old code will only align hot loop to 32 bytes when the LoopSize larger than
16 bytes and smaller than 32 bytes, this patch will align the innermost hot loop
to 32 bytes not only for the hot loop whose size is 16~32 bytes.
Reviewed By: steven.zhang, jsji
Differential Revision: https://reviews.llvm.org/D61228
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363495 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
When using ConstantExpr we often need the result of the expression to be kept in the AST. Currently this is done on a by the node that needs the result and has been done multiple times for enumerator, for constexpr variables... . This patch adds to ConstantExpr the ability to store the result of evaluating the expression. no functional changes expected.
Changes:
- Add trailling object to ConstantExpr that can hold an APValue or an uint64_t. the uint64_t is here because most ConstantExpr yield integral values so there is an optimized layout for integral values.
- Add basic* serialization support for the trailing result.
- Move conversion functions from an enum to a fltSemantics from clang::FloatingLiteral to llvm::APFloatBase. this change is to make it usable for serializing APValues.
- Add basic* Import support for the trailing result.
- ConstantExpr created in CheckConvertedConstantExpression now stores the result in the ConstantExpr Node.
- Adapt AST dump to print the result when present.
basic* : None, Indeterminate, Int, Float, FixedPoint, ComplexInt, ComplexFloat,
the result is not yet used anywhere but for -ast-dump.
Reviewers: rsmith, martong, shafik
Reviewed By: rsmith
Subscribers: rnkovacs, hiraditya, dexonsmith, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D62399
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363493 91177308-0d34-0410-b5e6-96231b3b80d8
Based on D59959, this switches SCEV to use unsigned/signed range
intersection based on the sign hint. This will prefer non-wrapping
ranges in the relevant domain. I've left the one intersection in
getRangeForAffineAR() to use the smallest intersection heuristic,
as there doesn't seem to be any obvious preference there.
Differential Revision: https://reviews.llvm.org/D60035
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363490 91177308-0d34-0410-b5e6-96231b3b80d8
If we can detect that saturating math that depends on an IV cannot
overflow, replace it with simple math. This is similar to the CVP
optimization from D62703, just based on a different underlying
analysis (SCEV vs LVI) that catches different cases.
Differential Revision: https://reviews.llvm.org/D62792
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363489 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts rL363474. -debug-only=isel was added to some tests that
don't specify `REQUIRES: asserts`. This causes failures on
-DLLVM_ENABLE_ASSERTIONS=off builds.
I chose to revert instead of fixing the tests because I'm not sure
whether we should add `REQUIRES: asserts` to more tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363482 91177308-0d34-0410-b5e6-96231b3b80d8
Current findBestLoopTop can find and move one kind of block to top, a latch block has one successor. Another common case is:
* a latch block
* it has two successors, one is loop header, another is exit
* it has more than one predecessors
If it is below one of its predecessors P, only P can fall through to it, all other predecessors need a jump to it, and another conditional jump to loop header. If it is moved before loop header, all its predecessors jump to it, then fall through to loop header. So all its predecessors except P can reduce one taken branch.
Differential Revision: https://reviews.llvm.org/D43256
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363471 91177308-0d34-0410-b5e6-96231b3b80d8
Currently you get extra waits, because waits are inserted for the
register dependencies of the call, and the function prolog waits on
everything.
Currently waits are still inserted on returns. It may make sense to
not do this, and wait in the caller instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363465 91177308-0d34-0410-b5e6-96231b3b80d8
This patch allows clang users to print out a list of supported CPU models using
clang [--target=<target triple>] --print-supported-cpus
Then, users can select the CPU model to compile to using
clang --target=<triple> -mcpu=<model> a.c
It is a handy feature to help cross compilation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363464 91177308-0d34-0410-b5e6-96231b3b80d8
This adds:
* documentation to the user manual
* nicer error message
* test for the error case
* test for the gold plugin
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363463 91177308-0d34-0410-b5e6-96231b3b80d8
There is a circular dependency between SROA and InferAddressSpaces
today that requires running both multiple times in order to be able to
eliminate all simple allocas and addrspacecasts. InferAddressSpaces
can't remove addrspacecasts when written to memory, and SROA helps
move pointers out of memory.
This should avoid inserting new commuting addrspacecasts with GEPs,
since there are unresolved questions about pointer wrapping between
different address spaces.
For now, don't replace volatile operations that don't match the alloca
addrspace, as it would change the address space of the access. It may
be still OK to insert an addrspacecast from the new alloca, but be
more conservative for now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363462 91177308-0d34-0410-b5e6-96231b3b80d8
The way SelectionDAG treats memory operands is very frustrating, and
by default drops them unless a property is set on the pattern. There
is no pattern for manually selected instructions, so this requires
manually setting them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363455 91177308-0d34-0410-b5e6-96231b3b80d8
Kernels seem to go directly to a section switch instead of emitting
.Lfunc_end. This fixes including all of the kernel metadata in the
check lines, which is undesirable most of the time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363452 91177308-0d34-0410-b5e6-96231b3b80d8
This extracts the LLVM distribution target handling into a support module.
Extraction will enable us to restructure the builds to support multiple
distribution configurations (e.g. developer and user) to permit us to build the
development package and the user package at once.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363440 91177308-0d34-0410-b5e6-96231b3b80d8
The NVPTX target is a bit unusual in that it's the only target without a
disassembler, and one of three targets without an asm parser (and the
first one of those three in the gn build). NVPTX doesn't have those
because it's not a binary format.
The CMake build checks for the existence of
{AsmParser,Disassembler}/CMakeLists.txt when setting
LLVM_ENUM_ASM_PARSERS / LLVM_ENUM_DISASSEBLERS
(http://llvm-cs.pcc.me.uk/CMakeLists.txt#744). The GN build doesn't want
to hit the disk for things like this, so instead I'm adding explicit
`targets_with_asm_parsers` and `targets_with_disassemblers` lists. Since
both are needed rarely, they are defined in their own gni files.
Differential Revision: https://reviews.llvm.org/D63210
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363437 91177308-0d34-0410-b5e6-96231b3b80d8
Now that the cycle between MCTargetDesc and TargetInfo is gone
(see revisions 360709 360718 360722 360724 360726 360731 360733 360735 360736),
remove the dependency from TargetInfo on MCTargetDesc:tablegen. In most
targets, this makes MCTargetDesc:tablegen have just a single use, so
inline it there.
For AArch64, ARM, and RISCV there's still a similar cycle between
MCTargetDesc and Utils, so the MCTargetDesc:tablegen indirection is
still needed there.
Differential Revision: https://reviews.llvm.org/D63200
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@363436 91177308-0d34-0410-b5e6-96231b3b80d8
Roman Lebedev