| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Section "Arguments" of `getelementptr` [1] says the first argument is a
type, the second argument is a pointer or a vector of pointers, and is
the base address to start from. Update `getelementptr` FAQ [2]
accordingly, based on discussion with David on the mailing list [3].
[1] http://llvm.org/docs/LangRef.html#getelementptr-instruction
[2] http://llvm.org/docs/GetElementPtr.html
[3] http://lists.llvm.org/pipermail/llvm-dev/2017-June/114294.html
Patch by Wei-Ren Chen!
Differential Revision: https://reviews.llvm.org/D34325
llvm-svn: 305662
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Background: http://lists.llvm.org/pipermail/llvm-dev/2017-May/112779.html
This change is to alter the prototype for the atomic memcpy intrinsic. The prototype itself is being changed to more closely resemble the semantics and parameters of the llvm.memcpy intrinsic -- to ease later combination of the llvm.memcpy and atomic memcpy intrinsics. Furthermore, the name of the atomic memcpy intrinsic is being changed to make it clear that it is not a generic atomic memcpy, but specifically a memcpy is unordered atomic.
Reviewers: reames, sanjoy, efriedma
Reviewed By: reames
Subscribers: mzolotukhin, anna, llvm-commits, skatkov
Differential Revision: https://reviews.llvm.org/D33240
llvm-svn: 305558
|
|
|
|
| |
llvm-svn: 305515
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Points to existing documentation for branch_weights and
function_entry_count, and adds an example for VP value profile metadata.
Reviewers: davidxl, reames
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34218
llvm-svn: 305475
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch is part of 3 patches that together form a single patch, but must be introduced in stages in order not to break things.
The way that LLVM interprets DW_OP_plus in DIExpression nodes is basically that of the DW_OP_plus_uconst operator since LLVM expects an unsigned constant operand. This unnecessarily restricts the DW_OP_plus operator, preventing it from being used to describe the evaluation of runtime values on the expression stack. These patches try to align the semantics of DW_OP_plus and DW_OP_minus with that of the DWARF definition, which pops two elements off the expression stack, performs the operation and pushes the result back on the stack.
This is done in three stages:
• The first patch (LLVM) adds support for DW_OP_plus_uconst.
• The second patch (Clang) contains changes all its uses from DW_OP_plus to DW_OP_plus_uconst.
• The third patch (LLVM) changes the semantics of DW_OP_plus and DW_OP_minus to be in line with its DWARF meaning. This patch includes the bitcode upgrade from legacy DIExpressions.
Patch by Sander de Smalen.
Reviewers: echristo, pcc, aprantl
Reviewed By: aprantl
Subscribers: fhahn, javed.absar, aprantl, llvm-commits
Differential Revision: https://reviews.llvm.org/D33894
llvm-svn: 305386
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch is part of 3 patches that together form a single patch, but must be introduced in stages in order not to break things.
The way that LLVM interprets DW_OP_plus in DIExpression nodes is basically that of the DW_OP_plus_uconst operator since LLVM expects an unsigned constant operand. This unnecessarily restricts the DW_OP_plus operator, preventing it from being used to describe the evaluation of runtime values on the expression stack. These patches try to align the semantics of DW_OP_plus and DW_OP_minus with that of the DWARF definition, which pops two elements off the expression stack, performs the operation and pushes the result back on the stack.
This is done in three stages:
• The first patch (LLVM) adds support for DW_OP_plus_uconst.
• The second patch (Clang) contains changes all its uses from DW_OP_plus to DW_OP_plus_uconst.
• The third patch (LLVM) changes the semantics of DW_OP_plus and DW_OP_minus to be in line with its DWARF meaning. This patch includes the bitcode upgrade from legacy DIExpressions.
Patch by Sander de Smalen.
Reviewers: pcc, echristo, aprantl
Reviewed By: aprantl
Subscribers: fhahn, aprantl, javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D33892
llvm-svn: 305304
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Add a lexicon entry for global value numbering.
Reviewers: davide, majnemer
Reviewed By: davide
Subscribers: llvm-commits, inouehrs
Differential Revision: https://reviews.llvm.org/D33664
llvm-svn: 305270
|
|
|
|
|
|
| |
And reverse the ownership between DICompileUnit and DISubprogram.
llvm-svn: 305254
|
|
|
|
|
|
|
|
|
|
| |
named metadata.
The new metadata is easier to manipulate than module flags.
Differential Revision: https://reviews.llvm.org/D31349
llvm-svn: 305227
|
|
|
|
|
|
|
|
|
|
| |
This is to reflect the evolving nature of the tool as being
useful for more than just dumping PDBs, as it can do many other
things.
Differential Revision: https://reviews.llvm.org/D34062
llvm-svn: 305106
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D34001
llvm-svn: 304995
|
|
|
|
|
|
|
|
| |
The FirePro and Radeon versions of Hawaii have different 64 bit floating point configurations so use distinct target names for them. Rename the target name for Kabini to accommodate.
Differential Revision: https://reviews.llvm.org/D34016
llvm-svn: 304959
|
|
|
|
|
|
|
|
| |
Builds sucessfully with Sphinx v1.5.5
Differential Revision: https://reviews.llvm.org/D33736
llvm-svn: 304853
|
|
|
|
|
|
|
|
|
| |
Remove extra tabs.
Builds sucessfully with Sphinx v1.5.5
Differential Revision: https://reviews.llvm.org/D33736
llvm-svn: 304848
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D33736
llvm-svn: 304831
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some InstCombine optimizations already rely on the result being poison
rather than undef.
For example, the following rewrite is wrong if undef is used:
; (1 << Y) * X -> X << Y
%Op0 = shl 1, %Y
%r = mul %Op0, %Op1
=>
%r = shl %Op1, %Y
ERROR: Mismatch in values for i4 %r
Example:
i4 %Y = 0x8 (8, -8)
i4 %Op0 = 0x0 (0)
i4 %Op1 = 0x0 (0)
source: 0x0 (0)
target: 0x1 (1)
The optimization is correct if poison is returned instead:
http://rise4fun.com/Alive/ygX
Differential Revision: https://reviews.llvm.org/D33654
llvm-svn: 304780
|
|
|
|
| |
llvm-svn: 304370
|
|
|
|
|
|
|
|
| |
Following the request made in https://reviews.llvm.org/D32871, the
general documentation of the Vectorization Plan is hereby placed
under docs/Proposals.
llvm-svn: 304161
|
|
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D32319
llvm-svn: 303922
|
|
|
|
|
|
| |
By default, CMake uses a 32-bit toolchain, even when on a 64-bit platform targeting a 64-bit build. However, due to the size of the binaries involved, this can cause linker instabilities (such as the linker running out of memory). Guide people to the correct solution to get CMake to use the native toolchain.
llvm-svn: 303912
|
|
|
|
| |
llvm-svn: 303896
|
|
|
|
| |
llvm-svn: 303769
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The default behavior of -Rpass-analysis=loop-vectorizer is to report only the
first reason encountered for not vectorizing, if one is found, at which time the
vectorizer aborts its handling of the loop. This patch allows multiple reasons
for not vectorizing to be identified and reported, at the potential expense of
additional compile-time, under allowExtraAnalysis which can currently be turned
on by Clang's -fsave-optimization-record and opt's -pass-remarks-missed.
Removed from LoopVectorizationLegality::canVectorize() the redundant checking
and reporting if we CantComputeNumberOfIterations, as LAI::canAnalyzeLoop() also
does that. This redundancy is caught by a lit test once multiple reasons are
reported.
Patch initially developed by Dror Barak.
Differential Revision: https://reviews.llvm.org/D33396
llvm-svn: 303613
|
|
|
|
|
|
|
|
| |
Patch by chenwj!
Differential Revision: https://reviews.llvm.org/D32929
llvm-svn: 303499
|
|
|
|
|
|
|
| |
Fixed "most platform" to read "most platforms", and changed "are not
using the same" to "use different" as a drive-by.
llvm-svn: 303487
|
|
|
|
| |
llvm-svn: 303486
|
|
|
|
|
|
|
| |
By default, git creates "llvm-project-20170507" directory,
but we want to create "llvm-project" directory.
llvm-svn: 303124
|
|
|
|
|
|
|
|
| |
Patch by Wei-Ren Chen (陳韋任)!
Differential Revision: https://reviews.llvm.org/D32964
llvm-svn: 302950
|
|
|
|
|
|
|
|
| |
Based on patch by Patrick Boettcher and Chris Dewhurst.
Differential Revision: https://reviews.llvm.org/D29116
llvm-svn: 302911
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch extends llvm-ir to allow attributes to be set on global variables.
An RFC was sent out earlier by my colleague James Molloy: http://lists.llvm.org/pipermail/cfe-dev/2017-March/053100.html
A key part of that proposal was to extend LLVM-IR to carry attributes on global variables.
This generic feature could be useful for multiple purposes.
In our present context, it would be useful to carry user specified sections for bss/rodata/data.
Reviewed by: Jonathan Roelofs, Reid Kleckner
Differential Revision: https://reviews.llvm.org/D32009
llvm-svn: 302794
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- This change allows targets to opt-in to using them instead of the log2
shufflevector algorithm.
- The SLP and Loop vectorizers have the common code to do shuffle reductions
factored out into LoopUtils, and now have a unified interface for generating
reductions regardless of the preference of the target. LoopUtils now uses TTI
to determine what kind of reductions the target wants to handle.
- For CodeGen, basic legalization support is added.
Differential Revision: https://reviews.llvm.org/D30086
llvm-svn: 302514
|
|
|
|
|
|
|
|
| |
This reverts commit r302054.
Re-commit now that I have fixes for clang/lld.
llvm-svn: 302499
|
|
|
|
| |
llvm-svn: 302498
|
|
|
|
| |
llvm-svn: 302459
|
|
|
|
| |
llvm-svn: 302456
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- MIParser: If the successor list is not specified successors will be
added based on basic block operands in the block and possible
fallthrough.
- MIRPrinter: Adds a new `simplify-mir` option, with that option set:
Skip printing of block successor lists in cases where the
parser is guaranteed to reconstruct it. This means we still print the
list if some successor cannot be determined (happens for example for
jump tables), if the successor order changes or branch probabilities
being unequal.
Differential Revision: https://reviews.llvm.org/D31262
llvm-svn: 302289
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Add an entry to the Lexicon for "BDCE."
Reviewers: jmolloy, hfinkel
Reviewed By: jmolloy
Differential Revision: https://reviews.llvm.org/D31861
llvm-svn: 302169
|
|
|
|
|
|
|
|
| |
This reverts commit r302025.
clang and lld need to be updated too so they don't break with this patch.
llvm-svn: 302054
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: chandlerc, beanz, mgorny
Reviewed By: beanz
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31773
llvm-svn: 302025
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes PR31789 - When loop-vectorize tries to use these intrinsics for a
non-default address space pointer we fail with a "Calling a function with a
bad singature!" assertion. This patch solves this by adding the 'vector of
pointers' argument as an overloaded type which will determine the address
space.
Differential revision: https://reviews.llvm.org/D31490
llvm-svn: 302018
|
|
|
|
| |
llvm-svn: 301985
|
|
|
|
|
|
|
|
|
|
|
| |
Document the 'code' data type, and that value{15-17} is different to
value{17-15}.
Patch by @chenwj (Wei-Ren Chen).
Differential Revision: https://reviews.llvm.org/D32117
llvm-svn: 301920
|
|
|
|
| |
llvm-svn: 301773
|
|
|
|
|
|
|
|
| |
This attribute tells the optimizer that the function may be speculated.
Patch by Tom Stellard
llvm-svn: 301680
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In some cases LLVM (especially the SLP vectorizer) will create vectors
that are 256 bytes (or larger). Given that this is intentional[0] is
likely to get more common, this patch updates the StackMap binary
format to deal with the spill locations for said vectors.
This change also bumps the stack map version from 2 to 3.
[0]: https://reviews.llvm.org/D32533#738350
Reviewers: reames, kavon, skatkov, javed.absar
Subscribers: mcrosier, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D32629
llvm-svn: 301615
|
|
|
|
| |
llvm-svn: 301591
|
|
|
|
|
|
|
|
|
| |
Generate the better include paths. Instead of #include <llvm_header.h> doxygen
produces #include "llvm/Folder/llvm_header.h"
Patch by Yuka Takahashi (D32342)!
llvm-svn: 301569
|
|
|
|
| |
llvm-svn: 301545
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commits were:
"Use WeakVH instead of WeakTrackingVH in AliasSetTracker's UnkownInsts"
"Add a new WeakVH value handle; NFC"
"Rename WeakVH to WeakTrackingVH; NFC"
The changes assumed pointers are 8 byte aligned on all architectures.
llvm-svn: 301429
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
I plan to use WeakVH to mean "nulls itself out on deletion, but does
not track RAUW" in a subsequent commit.
Reviewers: dblaikie, davide
Reviewed By: davide
Subscribers: arsenm, mehdi_amini, mcrosier, mzolotukhin, jfb, llvm-commits, nhaehnle
Differential Revision: https://reviews.llvm.org/D32266
llvm-svn: 301424
|