| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In the context of http://wg21.link/lwg2445 C++ uses the concept of
'stronger' ordering but doesn't define it properly. This should be fixed
in C++17 barring a small question that's still open.
The code currently plays fast and loose with the AtomicOrdering
enum. Using an enum class is one step towards tightening things. I later
also want to tighten related enums, such as clang's
AtomicOrderingKind (which should be shared with LLVM as a 'C++ ABI'
enum).
This change touches a few lines of code which can be improved later, I'd
like to keep it as NFC for now as it's already quite complex. I have
related changes for clang.
As a follow-up I'll add:
bool operator<(AtomicOrdering, AtomicOrdering) = delete;
bool operator>(AtomicOrdering, AtomicOrdering) = delete;
bool operator<=(AtomicOrdering, AtomicOrdering) = delete;
bool operator>=(AtomicOrdering, AtomicOrdering) = delete;
This is separate so that clang and LLVM changes don't need to be in sync.
Reviewers: jyknight, reames
Subscribers: jyknight, llvm-commits
Differential Revision: http://reviews.llvm.org/D18775
llvm-svn: 265602
|
|
|
|
|
|
|
|
|
|
|
| |
This makes it possible to distinguish between mesa shaders
and other kernels even in the presence of compute shaders.
Patch By: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Differential Revision: http://reviews.llvm.org/D18559
llvm-svn: 265589
|
|
|
|
|
|
|
| |
r265515, this time with the correct fix. file inside DISubprogram is not
mandatory.
llvm-svn: 265586
|
|
|
|
|
|
| |
Thanks to Rafael for the suggestion!
llvm-svn: 265579
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use a DenseSet instead of a DenseMap for constants in LLVMContextImpl.
Last time I looked at this was some time before r223588, when
DenseSet<V> had no advantage over DenseMap<V,char>. After r223588,
there's a 50% memory savings.
This is all mechanical. There were little bits of missing API from
DenseSet so I added the trivial implementations:
- iterator::operator++(int)
- template <class LookupKeyT> insert_as(ValueTy, LookupKeyT)
There should be no functionality change, just reduced memory consumption
(this wasn't on a profile or anything; just a cleanup I stumbled on).
llvm-svn: 265577
|
|
|
|
|
|
|
| |
The MDStringCache doesn't need to be explicitly cleared before
destruction. The destructor handles it at least as efficiently.
llvm-svn: 265576
|
|
|
|
|
|
|
| |
We never delete any MDString until the context is destroyed. Might as
well throw them onto a BumpPtrAllocator.
llvm-svn: 265520
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of copying arguments from the source function to the
destination, steal them. This has a few advantages.
- The ValueMap doesn't need to be seeded with (or cleared of)
Arguments.
- Often the destination function won't have created any arguments yet,
so this avoids malloc traffic.
- Argument names don't need to be copied.
Because argument lists are lazy, this required a new
Function::stealArgumentListFrom helper.
llvm-svn: 265519
|
|
|
|
|
|
|
| |
This reverts commit r265515 as lots of tests need to be fixed before
this actually can go in.
llvm-svn: 265517
|
|
|
|
| |
llvm-svn: 265515
|
|
|
|
| |
llvm-svn: 265514
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17863
llvm-svn: 265480
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a common parent class for ConstantArray, ConstantVector, and
ConstantStruct called ConstantAggregate. These are the aggregate
subclasses of Constant that take operands.
This is mainly a cleanup, adding common `isa` target and removing
duplicated code. However, it also simplifies caching which constants
point transitively at `GlobalValue` (a possible future direction).
llvm-svn: 265466
|
|
|
|
|
|
|
| |
Use the same assertion as ConstantArray. Vectors should have the right
number of elements.
llvm-svn: 265463
|
|
|
|
| |
llvm-svn: 265434
|
|
|
|
|
|
|
|
| |
Patch by Nicole Mazzuca <npmazzuca@gmail.com>.
Differential Revision: http://reviews.llvm.org/D18736
llvm-svn: 265394
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: The assert code is introduced by r265370.
Reviewers: bkramer
Subscribers: tejohnson
Differential Revision: http://reviews.llvm.org/D18786
llvm-svn: 265383
|
|
|
|
|
|
|
|
|
|
|
| |
Second part extracted from http://reviews.llvm.org/D15525
Use GlobalIndirectSymbol in all cases when aliases and ifuncs have
something in common.
Differential Revision: http://reviews.llvm.org/D18754
llvm-svn: 265382
|
|
|
|
|
|
|
|
| |
Refactor common code that queries the ModuleSummaryIndex for a value's
GlobalValueInfo struct into getGlobalValueInfo helper methods, which
will also be used by D18763.
llvm-svn: 265370
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
I encountered this issue when constant folding during inlining tried to
fold away a bitcast of a double to an x86_mmx, which is not an integral
type. The test case exposes the same issue with a smaller code snippet
during early CSE.
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18528
llvm-svn: 265367
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were using array_pod_sort on an array of type 'Attribute', which
wraps a pointer to AttributeImpl. For the most part this didn't matter
because the printing code prints enum attributes in a defined order, but
integer attributes such as 'align' and 'dereferenceable' were not
ordered.
Furthermore, AttributeImpl::operator< was broken for integer attributes.
An integer attribute is a kind and an integer value, and both pieces
need to be compared.
By fixing the comparison operator, we can go back to std::sort, and
things look good now. This should fix clang arm-swiftcall.c test
failures on Windows.
llvm-svn: 265361
|
|
|
|
| |
llvm-svn: 265353
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RAUW support on MDNode usually requires an extra allocation for
ReplaceableMetadataImpl. This is only strictly necessary if there are
tracking references to the MDNode. Make the construction of
ReplaceableMetadataImpl lazy, so that we don't get allocations if we
don't need them.
Since MDNode::isResolved now checks MDNode::isTemporary and
MDNode::NumUnresolved instead of whether a ReplaceableMetadataImpl is
allocated, the internal changes are intrusive (at various internal
checkpoints, isResolved now has a different answer).
However, there should be no real functionality change here; just
slightly lazier allocation behaviour. The external semantics should be
identical.
llvm-svn: 265279
|
|
|
|
| |
llvm-svn: 265277
|
|
|
|
|
| |
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265217
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This should make the code more readable, especially all the map declarations.
Reviewers: tejohnson
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18721
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265215
|
|
|
|
|
| |
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265212
|
|
|
|
|
|
|
| |
Suggested by Sean Silva.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265211
|
|
|
|
|
|
|
|
|
|
|
|
| |
A ``swifterror`` attribute can be applied to a function parameter or an
AllocaInst.
This commit does not include any target-specific change. The target-specific
optimization will come as a follow-up patch.
Differential Revision: http://reviews.llvm.org/D18092
llvm-svn: 265189
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of "build-id"
This is intended to be used for ThinLTO incremental build.
Differential Revision: http://reviews.llvm.org/D18213
This is a recommit of r265095 after fixing the Windows issues.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265111
|
|
|
|
|
|
|
|
| |
This reverts commit r265096, r265095, and r265094.
Windows build is broken, and the validation does not pass.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265102
|
|
|
|
|
|
|
|
|
|
|
| |
of "build-id"
This is intended to be used for ThinLTO incremental build.
Differential Revision: http://reviews.llvm.org/D18213
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 265095
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when compiling with LTO.
r244523 a new class DiagnosticInfoOptimizationRemarkAnalysisAliasing for
optimization analysis remarks related to pointer aliasing without
guarding it in isDiagnosticEnabled in LLVMContext.cpp. This caused the
diagnostic message to be printed unconditionally when compiling with
LTO.
This commit cleans up isDiagnosticEnabled and makes sure all the
vectorization optimization remarks are guarded.
rdar://problem/25382153
llvm-svn: 265084
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This mostly cosmetic patch moves the DebugEmissionKind enum from DIBuilder
into DICompileUnit. DIBuilder is not the right place for this enum to live
in — a metadata consumer should not have to include DIBuilder.h.
I also added a Verifier check that checks that the emission kind of a
DICompileUnit is actually legal.
http://reviews.llvm.org/D18612
<rdar://problem/25427165>
llvm-svn: 265077
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is a part of http://reviews.llvm.org/D15525
GlobalIndirectSymbol class contains common implementation for both
aliases and ifuncs. This patch should be NFC change that just prepare
common code for ifunc support.
Differential Revision: http://reviews.llvm.org/D18433
llvm-svn: 265016
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As discussed on llvm-dev[1].
This change adds the basic boilerplate code around having this intrinsic
in LLVM:
- Changes in Intrinsics.td, and the IR Verifier
- A lowering pass to lower @llvm.experimental.guard to normal
control flow
- Inliner support
[1]: http://lists.llvm.org/pipermail/llvm-dev/2016-February/095523.html
Reviewers: reames, atrick, chandlerc, rnk, JosephTremoulet, echristo
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D18527
llvm-svn: 264976
|
|
|
|
|
|
|
| |
r264884 introduced a helper to escape the backslashes in the source file
path, but I since discovered an existing mechanism to escape strings.
llvm-svn: 264936
|
|
|
|
|
|
|
| |
This restores commit 264869, with a fix for windows bots to properly
escape '\' in the path when serializing out. Added test.
llvm-svn: 264884
|
|
|
|
|
|
|
|
|
| |
This reverts commit r264869. I am seeing Windows bot failures due to the
"\" in the path being mishandled at some point (seems to be interpreted
wrongly at some point and llvm-as | llvm-dis is yielding some junk
characters). Need to investigate.
llvm-svn: 264871
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change serializes out and in the SourceFileName to LLVM assembly
so that it is preserved through "llvm-dis | llvm-as". This is
necessary to ensure that the global identifiers created for local values
in the module summary index are the same even if the bitcode is
streamed out and read back from LLVM assembly.
Serializing the summary itself to LLVM assembly is in progress.
Reviewers: joker.eph
Subscribers: llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D18588
llvm-svn: 264869
|
|
|
|
| |
llvm-svn: 264823
|
|
|
|
|
|
|
|
|
|
|
|
| |
Create a common accessor, DbgInfoIntrinsic::getVariableLocation, which
doesn't care about the type of debug info intrinsic. Use this to
further unify the implementations of DbgDeclareInst::getAddress and
DbgValueInst::getValue.
Besides being a cleanup, I'm planning to use this to prepare DEBUG
output without having to branch on the concrete type.
llvm-svn: 264767
|
|
|
|
|
|
|
|
|
|
|
| |
Since we have moved to a model where functions are imported in bulk from
each source module after making summary-based importing decisions, there
is no longer a need to link metadata as a postpass, and all users have
been removed.
This essentially reverts r255909 and follow-on fixes.
llvm-svn: 264763
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17866
llvm-svn: 264754
|
|
|
|
|
|
|
|
|
| |
A DICompileUnit that is not listed in llvm.dbg.cu will cause assertion
failures and/or crashes in the backend. The Verifier should reject this.
rdar://problem/25369499
llvm-svn: 264657
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reject the following IR as malformed (assuming that %entry, %next are
not in a loop):
next:
%y = phi i32 [ 0, %entry ]
%x = phi i32 [ %y, %entry ]
Such PHI nodes came up in PR26718. While there was no consensus on
whether or not this is valid IR, most opinions on that bug and in a
discussion on the llvm-dev mailing list tended towards a
"strict interpretation" (term by Joseph Tremoulet) of PHI node uses.
Also, the language reference explicitly states that "the use of each
incoming value is deemed to occur on the edge from the corresponding
predecessor block to the current block" and
`DominatorTree::dominates(Instruction*, Use&)` uses this definition as
well.
For the code mentioned in PR15384, clang does not compile to such PHIs
(anymore?). The test case still hangs when replacing `%tmp6` with `%tmp`
in revisions before r176366 (where PR15384 has been fixed). The
occurrence of %tmp6 therefore was probably unintentional. Its value is
not used except in other PHIs.
Reviewers: majnemer, reames, JosephTremoulet, bkramer, grosser, jdoerfert, kparzysz, sanjoy
Differential Revision: http://reviews.llvm.org/D18443
llvm-svn: 264528
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Loading IR with debug info improves MDString::get() from 19ms to 10ms.
This is a rework of D16597 with adding an "emplace" method on the StringMap
to avoid requiring the MDString move ctor to be public.
Reviewers: dexonsmith
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17920
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 264386
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
These are just helpers calling their static counter part to
simplify client code.
Reviewers: tejohnson
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18339
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 264382
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove logic to upgrade !llvm.loop by changing the MDString tag
directly. This old logic would check (and change) arbitrary strings
that had nothing to do with loop metadata. Instead, check !llvm.loop
attachments directly, and change which strings get attached.
Rather than updating the assembly-based upgrade, drop it entirely. It
has been quite a while since we supported upgrading textual IR.
llvm-svn: 264373
|
|
|
|
|
|
|
|
|
|
| |
This reserves an MDKind for !llvm.loop, which allows callers to avoid a
string-based lookup. I'm not sure why it was missing.
There should be no functionality change here, just a small compile-time
speedup.
llvm-svn: 264371
|