| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We put empty object files in archives, which causes MSVC's linker to
complain about these objects not defining any previously undefined
symbols. Since we do it on purpose, this only creates noise during
the build process. This patch causes us to suppress the warnings.
Reviewers: rnk, samsonov
Subscribers: dberris, mgorny
Differential Revision: https://reviews.llvm.org/D28262
llvm-svn: 291011
|
|
|
|
| |
llvm-svn: 291010
|
|
|
|
| |
llvm-svn: 291009
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix early-exit analysis for memory operation pairing when operations are
not emitted in ascending order.
Reviewers: mcrosier, t.p.northover
Subscribers: aemerson, rengolin, llvm-commits
Differential Revision: https://reviews.llvm.org/D28251
llvm-svn: 291008
|
|
|
|
|
|
|
|
|
|
|
| |
IntrusiveRefCntPtr"
Breaks Clang's use of bitcode. Reverting until I have a fix to go with
it there.
This reverts commit r291006.
llvm-svn: 291007
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IntrusiveRefCntPtr
If this is a problem for anyone (shared_ptr is two pointers in size,
whereas IntrusiveRefCntPtr is 1 - and the ref count control block that
make_shared adds is probably larger than the one int in RefCountedBase)
I'd prefer to address this by adding a lower-overhead version of
shared_ptr (possibly refactoring IntrusiveRefCntPtr into such a thing)
to avoid the intrusiveness - this allows memory ownership to remain
orthogonal to types and at least to me, seems to make code easier to
understand (since no implicit ownership acquisition can happen).
llvm-svn: 291006
|
|
|
|
|
|
|
|
|
|
| |
std::shared_ptr/make_shared
The intrusive nature of the reference counting is not required/used
here, so simplify the ownership model to make the code easier to
understand.
llvm-svn: 291005
|
|
|
|
| |
llvm-svn: 291004
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change aims to unify and correct our logic for when we need to allow for
the possibility of the linker adding a TOC restoration instruction after a
call. This comes up in two contexts:
1. When determining tail-call eligibility. If we make a tail call (i.e.
directly branch to a function) then there is no place for the linker to add
a TOC restoration.
2. When determining when we need to add a nop instruction after a call.
Likewise, if there is a possibility that the linker might need to add a
TOC restoration after a call, then we need to put a nop after the call
(the bl instruction).
First problem: We were using similar, but different, logic to decide (1) and
(2). This is just wrong. Both the resideInSameModule function (used when
determining tail-call eligibility) and the isLocalCall function (used when
deciding if the post-call nop is needed) were supposed to be determining the
same underlying fact (i.e. might a TOC restoration be needed after the call).
The same logic should be used in both places.
Second problem: The logic in both places was wrong. We only know that two
functions will share the same TOC when both functions come from the same
section of the same object. Otherwise the linker might cause the functions to
use different TOC base addresses (unless the multi-TOC linker option is
disabled, in which case only shared-library boundaries are relevant). There are
a number of factors that can cause functions to be placed in different sections
or come from different objects (-ffunction-sections, explicitly-specified
section names, COMDAT, weak linkage, etc.). All of these need to be checked.
The existing logic only checked properties of the callee, but the properties of
the caller must also be checked (for example, calling from a function in a
COMDAT section means calling between sections).
There was a conceptual error in the resideInSameModule function in that it
allowed tail calls to functions with weak linkage and protected/hidden
visibility. While protected/hidden visibility does prevent the function
implementation from being replaced at runtime (via interposition), it does not
prevent the linker from using an alternate implementation at link time (i.e.
using some strong definition to replace the provided weak one during linking).
If this happens, then we're still potentially looking at a required TOC
restoration upon return.
Otherwise, in general, the post-call nop is needed wherever ELF interposition
needs to be supported. We don't currently support ELF interposition at the IR
level (see http://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html
for more information), and I don't think we should try to make it appear to
work in the backend in spite of that fact. Unfortunately, because of the way
that the ABI works, we need to generate code as if we supported interposition
whenever the linker might insert stubs for the purpose of supporting it.
Differential Revision: https://reviews.llvm.org/D27231
llvm-svn: 291003
|
|
|
|
|
|
| |
we can pinpoint performance issues.
llvm-svn: 291002
|
|
|
|
| |
llvm-svn: 291001
|
|
|
|
|
|
|
| |
Reported by David Binderman and ack'ed by Teresa on IRC.
PR: 31527
llvm-svn: 291000
|
|
|
|
|
|
| |
instead. NFC.
llvm-svn: 290999
|
|
|
|
|
|
| |
Fixes PR31529.
llvm-svn: 290998
|
|
|
|
| |
llvm-svn: 290997
|
|
|
|
|
|
| |
No functionality change intended.
llvm-svn: 290996
|
|
|
|
|
|
| |
Fixes PR31528
llvm-svn: 290995
|
|
|
|
|
|
|
| |
Without this CHECK line, we may not detect incorrectly detected additional
regions at the end of the region tree.
llvm-svn: 290994
|
|
|
|
| |
llvm-svn: 290991
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change adds support for the -fno-delayed-template-parsing option in
clang-cl.exe. This allows developers using clang-cl.exe to opt out of
emulation of MSVC's non-conformant template instantiation implementation
while continuing to use clang-cl.exe for its emulation of cl.exe
command-line options. The default behavior of clang-cl.exe
(-fdelayed-template-parsing) is unchanged.
The MSVC Standard Library implementation uses clang-cl.exe with this
switch in its tests to ensure that the library headers work on compilers
with the conformant two-phase-lookup behavior.
Reviewers: majnemer, cfe-commits, DaveBartolomeo
Differential Revision: https://reviews.llvm.org/D22275
llvm-svn: 290990
|
|
|
|
| |
llvm-svn: 290989
|
|
|
|
|
|
| |
We no longer tail merge section names.
llvm-svn: 290988
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RefCountedBase
This roughly matches the semantics of std::enable_shared_from_this - that it
does not dictate the ownership model of all users, but constrains those users
taking advantage of the intrusive nature to do so only when there's a guarantee
that that's the ownership model being used for the object being passed.
Reviewers: jlebar
Differential Revision: https://reviews.llvm.org/D28245
llvm-svn: 290987
|
|
|
|
|
|
|
|
|
| |
The glibc dynamic loader rounds the size down, so without this the loader
will fail to change the memory protection for the last page.
Differential Revision: https://reviews.llvm.org/D28267
llvm-svn: 290986
|
|
|
|
| |
llvm-svn: 290984
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch includes updates for codegen of the target region for the NVPTX
device. It moves initializers from the compiler to the runtime and updates
the worker loop to assume parallel work is retrieved from the runtime. A
subsequent patch will update the codegen to retrieve the parallel work using
calls to the runtime. It includes the removal of the inline attribute
for the worker loop and disabling debug info in it.
This allows codegen for a target directive and serial execution on the
NVPTX device.
Reviewers: ABataev
Differential Revision: https://reviews.llvm.org/D28125
llvm-svn: 290983
|
|
|
|
|
|
|
|
|
| |
CUDA-8.0 comes with new headers which nvcc pre-includes via cuda_runtime.h
Clang now makes them available as well.
Differential Revision: https://reviews.llvm.org/D28301
llvm-svn: 290982
|
|
|
|
|
|
|
|
| |
The GUID should match between the RSDS and the PDB. This should repair
the build bots, though we should be ensuring that the GUIDs match.
Unfortunately, different build bots seem to be getting different GUIDs.
llvm-svn: 290981
|
|
|
|
| |
llvm-svn: 290980
|
|
|
|
|
|
|
|
|
| |
LLVM's integrated assembler will automatically switch to big objects
when there are more than 2**16 sections.
Patch by Kyra!
llvm-svn: 290979
|
|
|
|
|
|
|
|
| |
runtimes/CMakeLists.txt in LLVM passes OPENMP_STANDALONE_BUILD.
Differential Revision: https://reviews.llvm.org/D28280
llvm-svn: 290978
|
|
|
|
|
|
|
|
| |
v2: expose using amdgcn prefix
Differential Revision: https://reviews.llvm.org/D23511
llvm-svn: 290977
|
|
|
|
|
|
| |
reverse_iterator, move_iterator, array and Range Access' for C++17
llvm-svn: 290976
|
|
|
|
|
|
|
|
| |
The PDB GUID, Age, and version are tied together by the RSDS record in
the binary. Pass along the BuildId information into the createPDB to
allow us to tie the binary and the PDB together.
llvm-svn: 290975
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test case has been reduced from test/Analysis/RegionInfo/mix_1.ll and
provides us with a minimal example of a test case which caused problems while
working on an improved version of the RegionInfo analysis. We upstream this
test case, as it certainly can be helpful in future debugging and optimization
tests.
Test case reduced by Pratik Bhatu <cs12b1010@iith.ac.in>
llvm-svn: 290974
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
common inst"
This reapplies r289828 (reverted in r289833 as it broke the address sanitizer). The
debugloc is now only set when the instruction is not a call, as this causes the
verifier to assert (the inliner requires an inlinable callsite to have a debug loc
if the caller and callee have debug info).
Original commit message:
Simplify CFG will try to sink the last instruction in a series of basic blocks,
creating a "common" instruction in the successor block (sinkLastInstruction).
When it does this, the debug location of the single instruction should be the
merged debug locations of the commoned instructions.
Original review: https://reviews.llvm.org/D27590
llvm-svn: 290973
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Default member initializers cannot refer to constructor parameters, but modernize-default-member-init was trying to when the default constructor had default arguments.
Change the check to ignore default arguments to the default constructor.
Fixes PR31524.
Reviewers: alexfh, aaron.ballman
Subscribers: cfe-commits, JDevlieghere, Eugene.Zelenko
Differential Revision: https://reviews.llvm.org/D28287
llvm-svn: 290972
|
|
|
|
|
|
| |
The check script will use var names before they are declared, which filecheck doesn't like.
llvm-svn: 290971
|
|
|
|
|
|
| |
Missed var name
llvm-svn: 290970
|
|
|
|
| |
llvm-svn: 290969
|
|
|
|
|
|
|
| |
The commit r290960 checked the the basic block label name which isn't there
when clang is compiled in release mode.
llvm-svn: 290968
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: ioeric
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28279
llvm-svn: 290967
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Previously, a `\n` might be left in the old namespace and thus not copied to the new namespace, which is bad.
Reviewers: hokein
Subscribers: alexshap, cfe-commits
Differential Revision: https://reviews.llvm.org/D28282
llvm-svn: 290966
|
|
|
|
|
|
|
|
|
|
| |
These tests are missing a target triple and the -m elf_x86_64 gold option,
which makes them fail on non-x86 targets.
Differential revision: https://reviews.llvm.org/D28285
Reviewers: tejohnson
llvm-svn: 290965
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Change llvm-link to use the FunctionImporter handling, instead of
manually invoking the Linker. We still need to load the module
in llvm-link to do the desired testing for invalid import requests
(weak functions), and to get the GUID (in case the function is local).
Also change the drop-debug-info test to use llvm-link so that importing
is forced (in order to test debug info handling) and independent of
import logic changes.
Reviewers: mehdi_amini
Subscribers: mgorny, llvm-commits, aprantl
Differential Revision: https://reviews.llvm.org/D28277
llvm-svn: 290964
|
|
|
|
|
|
| |
Before it wasn't checking anything.
llvm-svn: 290963
|
|
|
|
|
|
| |
Actual codegen is much better than the extract+insert patterns that was assumed.
llvm-svn: 290962
|
|
|
|
|
|
|
| |
This CPU type was not previously recognized by LLVM which led to emitting
poor (and sometimes incorrect) code in some JIT workloads on such a machine.
llvm-svn: 290961
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in non-void functions that fall off at the end without returning a value when
compiling C++.
Clang uses the new compiler flag to determine when it should treat control flow
paths that fall off the end of a non-void function as unreachable. If
-fno-strict-return is on, the code generator emits the ureachable and trap
IR only when the function returns either a record type with a non-trivial
destructor or another non-trivially copyable type.
The primary goal of this flag is to avoid treating falling off the end of a
non-void function as undefined behaviour. The burden of undefined behaviour
is placed on the caller instead: if the caller ignores the returned value then
the undefined behaviour is avoided. This kind of behaviour is useful in
several cases, e.g. when compiling C code in C++ mode.
rdar://13102603
Differential Revision: https://reviews.llvm.org/D27163
llvm-svn: 290960
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Before:
declare function foo();
let x = 1;
After:
declare function foo();
let x = 1;
The problem was that clang-format would unconditionally try to parse a child block, even though ambient function declarations do not have a body (similar to forward declarations).
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D28246
llvm-svn: 290959
|