| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some ways this is a very boring port to the new pass manager as there
are no interesting analyses or dependencies or other oddities.
However, this does introduce the first good example of a transformation
pass with non-trivial state porting to the new pass manager. I've tried
to carve out patterns here to replicate elsewhere, and would appreciate
comments on whether folks like these patterns:
- A common need in the new pass manager is to effectively lift the pass
class and some of its state into a public header file. Prior to this,
LLVM used anonymous namespaces to provide "module private" types and
utilities, but that doesn't scale to cases where a public header file
is needed and the new pass manager will exacerbate that. The pattern
I've adopted here is to use the namespace-cased-name of the core pass
(what would be a module if we had them) as a module-private namespace.
Then utility and other code can be declared and defined in this
namespace. At some point in the future, we could even have
(conditionally compiled) code that used modules features when
available to do the same basic thing.
- I've split the actual pass run method in two in order to expose
a private method usable by the old pass manager to wrap the new class
with a minimum of duplicated code. I actually looked at a bunch of
ways to automate or generate these, but they are all quite terrible
IMO. The fundamental need is to extract the set of analyses which need
to cross this interface boundary, and that will end up being too
unpredictable to effectively encapsulate IMO. This is also
a relatively small amount of boiler plate that will live a relatively
short time, so I'm not too worried about the fact that it is boiler
plate.
The rest of the patch is totally boring but results in a massive diff
(sorry). It just moves code around and removes or adds qualifiers to
reflect the new name and nesting structure.
Differential Revision: http://reviews.llvm.org/D12773
llvm-svn: 247501
|
| |
|
|
|
|
| |
always_inline functions without a wrapper don't need to be in a COMDAT.
llvm-svn: 247500
|
| |
|
|
| |
llvm-svn: 247499
|
| |
|
|
| |
llvm-svn: 247498
|
| |
|
|
|
|
| |
FindAvailableLoadedValue()'s parameter MaxInstsToScan.
llvm-svn: 247497
|
| |
|
|
|
|
| |
GCC driver, for example cygwin, both "-mstackrealign" "-mno-stackrealign" are passed.
llvm-svn: 247496
|
| |
|
|
|
|
|
|
|
|
| |
Summary: This fixes a variety of typos in docs, code and headers.
Subscribers: jholewinski, sanjoy, arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D12626
llvm-svn: 247495
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current implementation may end up emitting an undefined reference for
an "inline __attribute__((always_inline))" function by generating an
"available_externally alwaysinline" IR function for it and then failing to
inline all the calls. This happens when a call to such function is in dead
code. As the inliner is an SCC pass, it does not process dead code.
Libc++ relies on the compiler never emitting such undefined reference.
With this patch, we emit a pair of
1. internal alwaysinline definition (called F.alwaysinline)
2a. A stub F() { musttail call F.alwaysinline }
-- or, depending on the linkage --
2b. A declaration of F.
The frontend ensures that F.inlinefunction is only used for direct
calls, and the stub is used for everything else (taking the address of
the function, really). Declaration (2b) is emitted in the case when
"inline" is meant for inlining only (like __gnu_inline__ and some
other cases).
This approach, among other nice properties, ensures that alwaysinline
functions are always internal, making it impossible for a direct call
to such function to produce an undefined symbol reference.
This patch is based on ideas by Chandler Carruth and Richard Smith.
llvm-svn: 247494
|
| |
|
|
|
|
| |
Should fix sanitizer-ppc64-linux1 bot.
llvm-svn: 247493
|
| |
|
|
|
|
|
|
|
|
| |
We had asserts in PHINode::addIncoming to check that the value types matched
the type of the PHI, and that the associated BB was not null. These did not
catch, however, later uses of setIncomingValue and setIncomingBlock (which are
called by addIncoming as well). Moving the asserts to PHINode::setIncoming*
provides better coverage. NFC.
llvm-svn: 247492
|
| |
|
|
|
|
|
|
|
| |
Revert "Always_inline codegen rewrite."
Breaks gdb & lldb tests.
Breaks on Fedora 22 x86_64.
llvm-svn: 247491
|
| |
|
|
| |
llvm-svn: 247490
|
| |
|
|
|
|
|
| |
It's fine to use sizeof on std::bitset<>, since it doesn't have any external
storage, everything's inside.
llvm-svn: 247489
|
| |
|
|
| |
llvm-svn: 247488
|
| |
|
|
|
|
|
|
|
|
| |
They are not fully functional yet, but this implements enough support for lld
itself to read them.
With that, delete the .so binary we were using for tests and start eating our
own dog food.
llvm-svn: 247487
|
| |
|
|
|
|
|
|
| |
it's not sufficient to prefer the declaration with more default arguments, or
the one that's visible; they might both be visible, but one of them might have
a visible default argument where the other has a hidden default argument.
llvm-svn: 247486
|
| |
|
|
| |
llvm-svn: 247485
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the pointer passed to the getVtablePrefix function was read from a freed
object, we may end up following pointers into objects on the heap and
printing bogus dynamic type names in diagnostics. However, we know that
vtable pointers will generally only point into memory mapped from object
files, not objects on the heap.
This change causes us to only follow pointers in a vtable if the vtable
and one of the virtual functions it points to appear to have appropriate
permissions (i.e. non-writable, and maybe executable), which will generally
exclude heap pointers.
Only enabled for Linux; this hasn't been tested on FreeBSD, and vtables are
writable on Mac (PR24782) so this won't work there.
Differential Revision: http://reviews.llvm.org/D12790
llvm-svn: 247484
|
| |
|
|
| |
llvm-svn: 247483
|
| |
|
|
|
|
|
|
| |
if they have the same alignment and one was 'this'.
Fixes PR24780.
llvm-svn: 247482
|
| |
|
|
|
|
| |
We were crashing before.
llvm-svn: 247481
|
| |
|
|
|
|
|
|
|
|
|
| |
Summary:
TempScop is basically a holder for AccFuncMap, the dictionary from BasicBlocks to IRAccess lists. We move the list into polly::Scop and remove the polly::TempScop class.
There is one small change in behavior: If ScopInfo finds that its AssumedContext is impossible, it bails out by deleting the Scop object. The TempScop::print (invoked with opt -polly-scops -analyze) cannot print the AccFuncMap anymore as it would with a separate TempScop.
Differential Revision: http://reviews.llvm.org/D12803
llvm-svn: 247480
|
| |
|
|
| |
llvm-svn: 247479
|
| |
|
|
| |
llvm-svn: 247478
|
| |
|
|
|
|
|
| |
I accidentally introduced a bug locally, and noticed that none of the tests
caught it. No longer!
llvm-svn: 247477
|
| |
|
|
| |
llvm-svn: 247476
|
| |
|
|
| |
llvm-svn: 247475
|
| |
|
|
| |
llvm-svn: 247474
|
| |
|
|
|
|
| |
This should fix the tests on Windows (failing due to mangling differencies).
llvm-svn: 247473
|
| |
|
|
| |
llvm-svn: 247472
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D12776
llvm-svn: 247471
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When compiling Polly without LLVM sources but with system-installed
LLVM, the build process would not honor the LLVM_ENABLE_ASSERTIONS
setting LLVM was compiled with, but effectively assume that it is
switched off when compiling. During unit-tests llvm-lit would still
query the LLVM_ENABLE_ASSERTIONS flag and enable tests which require
assertions. Even if enabled for LLVM, Polly does not output its debug
info and statistics in this this mode such that 7 tests fail.
To fix, we query llvm-config --assertion-mode and if on, enable
assertions as HandleLLVMOptions.cmake would do.
We cannot reliably use HandleLLVMOptions.cmake itself as the host's
LLVM build might have been built using automake and distributions
change file locations (e.g. Debian to
/usr/share/llvm-${VERSION}/cmake/HandleLLVMOptions.cmake).
llvm-svn: 247470
|
| |
|
|
| |
llvm-svn: 247469
|
| |
|
|
|
|
| |
command.
llvm-svn: 247468
|
| |
|
|
|
|
| |
When building with LTO the bootstrap builds need to depend on libLTO, llvm-ar, and llvm-ranlib, which all need to be passed into the bootstrap build. This functionality only works on Darwin.
llvm-svn: 247467
|
| |
|
|
|
|
|
| |
- Eliminate 'No such file or directory at scan-build line ...' error if '$RealBin/bin/clang' or '$RealBin/clang' directory does not exist.
- Eliminate 'Use of uninitialized value $Clang in concatenation (.) or string at scan-build line ...' error if help is displayed while $Clang was not found.
llvm-svn: 247466
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current implementation may end up emitting an undefined reference for
an "inline __attribute__((always_inline))" function by generating an
"available_externally alwaysinline" IR function for it and then failing to
inline all the calls. This happens when a call to such function is in dead
code. As the inliner is an SCC pass, it does not process dead code.
Libc++ relies on the compiler never emitting such undefined reference.
With this patch, we emit a pair of
1. internal alwaysinline definition (called F.alwaysinline)
2a. A stub F() { musttail call F.alwaysinline }
-- or, depending on the linkage --
2b. A declaration of F.
The frontend ensures that F.inlinefunction is only used for direct
calls, and the stub is used for everything else (taking the address of
the function, really). Declaration (2b) is emitted in the case when
"inline" is meant for inlining only (like __gnu_inline__ and some
other cases).
This approach, among other nice properties, ensures that alwaysinline
functions are always internal, making it impossible for a direct call
to such function to produce an undefined symbol reference.
This patch is based on ideas by Chandler Carruth and Richard Smith.
llvm-svn: 247465
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We used to only select an inheritance model if the pointer to member was
nullptr. Instead, select a model regardless of the member pointer's
value.
N.B. This bug was exposed by making member pointers report true for
isIncompleteType but has been latent since the member pointer scheme's
inception.
llvm-svn: 247464
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
considers as large
Add an option (-analyzer-config min-blocks-for-inline-large=14) to control the function
size the inliner considers as large, in relation to "max-times-inline-large". The option
defaults to the original hard coded behaviour, which I believe should be adjustable with
the other inlining settings.
The analyzer-config test has been modified so that the analyzer will reach the
getMinBlocksForInlineLarge() method and store the result in the ConfigTable, to ensure it
is dumped by the debug checker.
A patch by Sean Eveson!
Differential Revision: http://reviews.llvm.org/D12406
llvm-svn: 247463
|
| |
|
|
|
|
| |
This was not working correctly, leading to erroneously rejecting valid edits.
llvm-svn: 247462
|
| |
|
|
|
|
|
| |
This is in order to give LTO clients a chance to do some clean-up before
terminating the process.
llvm-svn: 247461
|
| |
|
|
|
|
| |
llvm.org/pr24778
llvm-svn: 247460
|
| |
|
|
|
|
| |
llvm.org/pr24777
llvm-svn: 247459
|
| |
|
|
|
|
| |
llvm.org/pr24772
llvm-svn: 247458
|
| |
|
|
|
|
|
|
| |
This is a trivial issue to fix, just marking it for later.
Windows prints function signatures a bit differently, and the
test expects a specific format.
llvm-svn: 247457
|
| |
|
|
|
|
| |
llvm.org/pr21765
llvm-svn: 247456
|
| |
|
|
|
|
| |
http://llvm.org/pr24764
llvm-svn: 247455
|
| |
|
|
| |
llvm-svn: 247454
|
| |
|
|
|
|
| |
It contains pathnames, so it can be different in each machine.
llvm-svn: 247453
|
| |
|
|
| |
llvm-svn: 247452
|