| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 253171
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The patch to move metadata linking after global value linking didn't
correctly map unmaterialized global values to null as desired. They
were in fact mapped to the source copy. It largely worked by accident
since most module linker clients destroyed the source module which
caused the source GVs to be replaced by null, but caused a failure with
LTO linking on Windows:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312869.html
The problem is that a null return value from materializeValueFor is
handled by mapping the value to self. This is the desired behavior when
materializeValueFor is passed a non-GlobalValue. The problem is how to
distinguish that case from the case where we really do want to map to
null.
This patch addresses this by passing in a new flag to the value mapper
indicating that unmapped global values should be mapped to null. Other
Value types are handled as before.
Note that the documented behavior of asserting on unmapped values when
the flag RF_IgnoreMissingValues isn't set is currently disabled with
FIXME notes due to bootstrap failures. I modified these disabled asserts
so when they are eventually enabled again it won't assert for the
unmapped values when the new RF_NullMapMissingGlobalValues flag is set.
I also considered using a callback into the value materializer, but a
flag seemed cleaner given that there are already existing flags.
I also considered modifying materializeValueFor to return the input
value when we want to map to source and then treat a null return
to mean map to null. However, there are other value materializer
subclasses that implement materializeValueFor, and they would all need
to be audited and the return values possibly changed, which seemed
error-prone.
Reviewers: dexonsmith, joker.eph
Subscribers: pcc, llvm-commits
Differential Revision: http://reviews.llvm.org/D14682
llvm-svn: 253170
|
|
|
|
|
|
| |
cvt intrinsics
llvm-svn: 253169
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Global to local demotion can speed up programs that use globals a lot. It is particularly useful with LTO, when the entire call graph is known and most functions have been internalized.
For a global to be demoted, it must only be accessed by one function and that function:
1. Must never recurse directly or indirectly, else the GV would be clobbered.
2. Must never rely on the value in GV at the start of the function (apart from the initializer).
GlobalOpt can already do this, but it is hamstrung and only ever tries to demote globals inside "main", because C++ gives extra guarantees about how main is called - once and only once.
In LTO mode, we can often prove the first property (if the function is internal by this point, we know enough about the callgraph to determine if it could possibly recurse). FunctionAttrs now infers the "norecurse" attribute for this reason.
The second property can be proven for a subset of functions by proving that all loads from GV are dominated by a store to GV. This is conservative in the name of compile time - this only requires a DominatorTree which is fairly cheap in the grand scheme of things. We could do more fancy stuff with MemoryDependenceAnalysis too to catch more cases but this appears to catch most of the useful ones in my testing.
llvm-svn: 253168
|
|
|
|
| |
llvm-svn: 253167
|
|
|
|
|
|
|
|
| |
This makes TypeAliasTemplateDecl accessible via LibClang and python bindings
Differential Revision: http://reviews.llvm.org/D13844
llvm-svn: 253166
|
|
|
|
|
|
|
|
| |
Expose the AutoType via LibClang and python bindings
Differential Revision: http://reviews.llvm.org/D13000
llvm-svn: 253165
|
|
|
|
| |
llvm-svn: 253164
|
|
|
|
|
|
| |
It broke layering violation. Reproducible with BUILD_SHARED_LIBS=ON.
llvm-svn: 253163
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current implementation of GEP visitor in InstCombine fails with assertion on Vector GEP with mix of scalar and vector types, like this:
getelementptr double, double* %a, <8 x i32> %i
(It fails to create a "sext" from <8 x i32> to <8 x i64>)
I fixed it and added some tests.
Differential Revision: http://reviews.llvm.org/D14485
llvm-svn: 253162
|
|
|
|
|
|
| |
Post-commit suggestion by Filipe Cabecinhas.
llvm-svn: 253161
|
|
|
|
|
|
|
|
| |
instructions.
Differential Revision: http://reviews.llvm.org/D14322
llvm-svn: 253160
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Document the differences between the isKnownWindowsMSVC() and isWindowsMSVC() methods on Triple.
Also removed the '\brief' Doxygen annotations - now that 'AUTOBRIEF' is set to on, they are unnecessary.
Subscribers: jfb, tberghammer, danalbert, srhines, dschuff
Differential Revision: http://reviews.llvm.org/D14110
llvm-svn: 253159
|
|
|
|
|
|
| |
DiagnosticsEngine and Preprocessor. Everything the preprocessor was being used for can be acquired from Sema.
llvm-svn: 253158
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The analyzer incorrectly treats captures as references if either the original
captured variable is a reference or the variable is captured by reference.
This causes the analyzer to crash when capturing a reference type by copy
(PR24914). Fix this by refering solely to the capture field to determine when a
DeclRefExpr for a lambda capture should be treated as a reference type.
https://llvm.org/bugs/show_bug.cgi?id=24914
rdar://problem/23524412
llvm-svn: 253157
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang tries to figure out if a call to abs is suspicious by looking
through implicit casts to look at the underlying, implicitly converted
type.
Interestingly, C has implicit conversions from pointer-ish types like
function to less exciting types like int. This trips up our 'abs'
checker because it doesn't know which variant of 'abs' is appropriate.
Instead, diagnose 'abs' called on function types upfront. This sort of
thing is highly suspicious and is likely indicative of a missing
pointer dereference/function call/array index operation.
This fixes PR25532.
llvm-svn: 253156
|
|
|
|
| |
llvm-svn: 253155
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There are currently two blocks with the METADATA_BLOCK id at module
scope. The first has the module-level metadata values (consisting of
some combination of METADATA_* record codes except for METADATA_KIND).
The second consists only of METADATA_KIND records. The latter is used
only in the METADATA_ATTACHMENT block within function blocks (for
metadata attached to instructions).
For ThinLTO we want to delay the parsing of module level metadata
until all functions have been imported from that module (there is some
bookkeeping used to suture it up when we read it during a post-pass).
However, we do need the METADATA_KIND records when parsing the function
body during importing, since those kinds are used as described above.
To simplify identification and parsing of just the block containing
the metadata kinds, use a different block id (METADATA_KIND_BLOCK_ID).
Support older bitcode without the new block id as well.
Reviewers: dexonsmith, joker.eph
Subscribers: davidxl, llvm-commits
Differential Revision: http://reviews.llvm.org/D14654
llvm-svn: 253154
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This diff approaches building the project natively on NetBSD with the autoconf/gmake framework.
Patch by Kamil Rytarowski. Thanks!
Reviewers: emaste, clayborg
Subscribers: tberghammer, joerg, brucem, lldb-commits
Differential Revision: http://reviews.llvm.org/D14531
llvm-svn: 253153
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: pkgsrc (on NetBSD) ships with python2.7-config.
Patch by Kamil Rytarowski. Thanks!
Reviewers: emaste, clayborg
Subscribers: brucem, lldb-commits, joerg
Differential Revision: http://reviews.llvm.org/D14528
llvm-svn: 253152
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This approach is tunable with custom paths for curses library.
It also detects whether there are requirements met.
I make use of it on NetBSD.
Patch by Kamil Rytarowski. Thanks!
Reviewers: clayborg
Subscribers: brucem, joerg, lldb-commits
Differential Revision: http://reviews.llvm.org/D14529
llvm-svn: 253151
|
|
|
|
| |
llvm-svn: 253150
|
|
|
|
| |
llvm-svn: 253149
|
|
|
|
| |
llvm-svn: 253148
|
|
|
|
| |
llvm-svn: 253147
|
|
|
|
| |
llvm-svn: 253146
|
|
|
|
|
|
|
|
|
|
| |
PT_GNU_STACK is a entry in the elf file format which contains the access rights (read, write, execute) of the stack,
it is always generated now. By default stack is not executable in this implementation.
-z execstack can be used to make executable.
Differential revision: http://reviews.llvm.org/D14571
llvm-svn: 253145
|
|
|
|
|
|
| |
Tidyup before diffs from new patch.
llvm-svn: 253144
|
|
|
|
|
|
| |
ParserDiagnostic.h diagnostics.
llvm-svn: 253143
|
|
|
|
| |
llvm-svn: 253142
|
|
|
|
| |
llvm-svn: 253141
|
|
|
|
|
|
| |
This removes a lot of code, which is A Good Thing(TM)
llvm-svn: 253140
|
|
|
|
| |
llvm-svn: 253139
|
|
|
|
| |
llvm-svn: 253138
|
|
|
|
| |
llvm-svn: 253137
|
|
|
|
| |
llvm-svn: 253136
|
|
|
|
| |
llvm-svn: 253135
|
|
|
|
| |
llvm-svn: 253134
|
|
|
|
| |
llvm-svn: 253133
|
|
|
|
|
|
| |
Baseline comparison to D14588
llvm-svn: 253132
|
|
|
|
|
|
| |
Makes it easier to track what tests are missing....
llvm-svn: 253131
|
|
|
|
|
|
| |
Improved tests as discussed in PR24580
llvm-svn: 253130
|
|
|
|
|
|
| |
This caused bot failures on ARM, e.g. http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/9068
llvm-svn: 253129
|
|
|
|
|
|
|
| |
These were implemented back in r244564. However, I forgot to update the
docs.
llvm-svn: 253128
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MCRelaxableFragment previously kept a copy of MCSubtargetInfo and
MCInst to enable re-encoding the MCInst later during relaxation. A copy
of MCSubtargetInfo (instead of a reference or pointer) was needed
because the feature bits could be modified by the parser.
This commit replaces the MCSubtargetInfo copy in MCRelaxableFragment
with a constant reference to MCSubtargetInfo. The copies of
MCSubtargetInfo are kept in MCContext, and the target parsers are now
responsible for asking MCContext to provide a copy whenever the feature
bits of MCSubtargetInfo have to be toggled.
With this patch, I saw a 4% reduction in peak memory usage when I
compiled verify-uselistorder.lto.bc using llc.
rdar://problem/21736951
Differential Revision: http://reviews.llvm.org/D14346
llvm-svn: 253127
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently we always recompute LCSSA for outer loops after unrolling an
inner loop. That leads to compile time problem when we have big loop
nests, and we can solve it by avoiding unnecessary work. For instance,
if w eonly do partial unrolling, we don't break LCSSA, so we don't need
to rebuild it. Also, if all exits from the inner loop are inside the
enclosing loop, then complete unrolling won't break LCSSA either.
I replaced unconditional LCSSA recomputation with conditional recomputation +
unconditional assert and added several tests, which were failing when I
experimented with it.
Soon I plan to follow up with a similar patch for recalculation of dominators
tree.
Reviewers: hfinkel, dexonsmith, bogner, joker.eph, chandlerc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14526
llvm-svn: 253126
|
|
|
|
|
|
|
|
|
| |
batons, and function pointers, and raw memory allocations instead of safer more modern constructs
This is a first pass at a cleanup of that code, modernizing the "type X clear" commands, and providing the basic infrastructure I plan to use all over
More cleanup will come over the next few days
llvm-svn: 253125
|
|
|
|
|
|
|
|
|
|
| |
MCSubtargetInfo in the subclasses into MCTargetAsmParser and define a
member function getSTI.
This is done in preparation for making changes to shrink the size of
MCRelaxableFragment. (see http://reviews.llvm.org/D14346).
llvm-svn: 253124
|
|
|
|
|
|
|
|
|
| |
r233345 started being stricter about typedef names for linkage purposes
in non-visible modules, but broke languages without the ODR.
rdar://23527954
llvm-svn: 253123
|
|
|
|
|
|
| |
it somewhat more consistent with how the feature is used.
llvm-svn: 253122
|