| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 269143
|
| |
|
|
| |
llvm-svn: 269142
|
| |
|
|
| |
llvm-svn: 269141
|
| |
|
|
|
|
|
|
|
| |
It is now less state-dependent and will allow easier comparing of
coverages of different units.
Differential Revision: http://reviews.llvm.org/D20085
llvm-svn: 269140
|
| |
|
|
| |
llvm-svn: 269139
|
| |
|
|
| |
llvm-svn: 269138
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: In sample profile, some branches may have profile missing due to profile inaccuracy. We want existing branch probability still valid after propagation.
Reviewers: hfinkel, davidxl, spatel
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D19948
llvm-svn: 269137
|
| |
|
|
|
|
|
|
|
|
|
| |
This means SelectCode unconditionally returns nullptr now. I'll follow
up with a change to make that return void as well, but it seems best
to keep that one very mechanical.
This is part of the work to have Select return void instead of an
SDNode *, which is in turn part of llvm.org/pr26808.
llvm-svn: 269136
|
| |
|
|
|
|
| |
for targeting win32. Investigating.
llvm-svn: 269135
|
| |
|
|
| |
llvm-svn: 269134
|
| |
|
|
|
|
|
| |
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/5110
Follow up from r269100.
llvm-svn: 269133
|
| |
|
|
|
|
|
|
| |
Unlike xN/wN, the size of vN is genuinely ambiguous in the assembly, so we
should try to infer what was intended from the type. But only down to 64-bits
(vN can never represent sN, hN or bN).
llvm-svn: 269132
|
| |
|
|
| |
llvm-svn: 269131
|
| |
|
|
| |
llvm-svn: 269130
|
| |
|
|
| |
llvm-svn: 269129
|
| |
|
|
| |
llvm-svn: 269128
|
| |
|
|
|
|
|
| |
This reverts commit r269125. It was in my tree when I ran "git svn dcommit".
It's really still under review.
llvm-svn: 269127
|
| |
|
|
|
|
|
| |
The CodeGen problem was fixed in r269101, but we still miscompiled assembly
that tried the same thing.
llvm-svn: 269126
|
| |
|
|
|
|
|
|
| |
Sort of the BB-local equivalent to idiom-recognizer: if we have a basic-block
that really implements a memcpy operation, backends can benefit from seeing
this.
llvm-svn: 269125
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before r268509, Clang would disable the loop unroll pass when optimizing
for size. That commit enabled it to be able to support unroll pragmas
in -Os builds. However, this regressed binary size in one of Chromium's
DLLs with ~100 KB.
This restores the original behaviour of no unrolling at -Os, but doing it
in LLVM instead of Clang makes more sense, and also allows the pragmas to
keep working.
Differential revision: http://reviews.llvm.org/D20115
llvm-svn: 269124
|
| |
|
|
| |
llvm-svn: 269123
|
| |
|
|
| |
llvm-svn: 269122
|
| |
|
|
|
|
|
|
|
| |
This patch extend loopreroll to allow the instruction chain
of loop control only IV has sext.
Differential Revision: http://reviews.llvm.org/D19820
llvm-svn: 269121
|
| |
|
|
|
|
|
|
|
|
| |
This is a bit of a spot fix for now. I'll try to fix this up more
comprehensively soon.
This is part of the work to have Select return void instead of an
SDNode *, which is in turn part of llvm.org/pr26808.
llvm-svn: 269120
|
| |
|
|
| |
llvm-svn: 269119
|
| |
|
|
|
|
| |
Oops. :(
llvm-svn: 269118
|
| |
|
|
| |
llvm-svn: 269117
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This only warns on casts of the address of a function defined in the
current TU. In this case, the fix is likely to be local and the warning
useful.
Here are some things we could experiment with in the future:
- Fire on declarations as well as definitions
- Limit the warning to non-void function prototypes
- Limit the warning to mismatches of caller and callee cleanup CCs
This warning is currently off by default while we study its usefulness.
Reviewers: thakis, rtrieu
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D17348
llvm-svn: 269116
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug introduced in r267623, where we got smarter and avoided to save
EAX before using it. However, we failed to check if any of the subregister of
EAX were alive and thus, missed cases where we have to save EAX before using it.
The problem may happen on every X86/i386/... platform.
This fixes llvm.org/PR27624
llvm-svn: 269115
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do simplifications common to all shift instructions based on the amount shifted:
1. If the shift amount is known larger than the bitwidth, the result is undefined.
2. If the valid bits of the shift amount are all known to be 0, it's a shift by zero, so the shift operand is the result.
Note that we could generalize the shift-by-zero transform into a shift-by-constant if all of the valid bits in the shift
amount are known, but that would have to be done in InstCombine rather than here because it would mean we need to create
a new shift instruction.
Differential Revision: http://reviews.llvm.org/D19874
llvm-svn: 269114
|
| |
|
|
|
|
|
|
|
|
| |
This is a bit of a spot fix for now. I'll try to fix this up more
comprehensively soon.
This is part of the work to have Select return void instead of an
SDNode *, which is in turn part of llvm.org/pr26808.
llvm-svn: 269112
|
| |
|
|
| |
llvm-svn: 269111
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the ModuleLevelChanges argument, and the ability to create new
subprograms for cloned functions. The latter was added without review in
r203662, but it has no in-tree clients (all non-test callers pass false
for ModuleLevelChanges [1], so it isn't reachable outside of tests). It
also isn't clear that adding a duplicate subprogram to the compile unit is
always the right thing to do when cloning a function within a module. If
this functionality comes back it should be accompanied with a more concrete
use case.
Furthermore, all in-tree clients add the returned function to the module.
Since that's pretty much the only sensible thing you can do with the function,
just do that in CloneFunction.
[1] http://llvm-cs.pcc.me.uk/lib/Transforms/Utils/CloneFunction.cpp/rCloneFunction
Differential Revision: http://reviews.llvm.org/D18628
llvm-svn: 269110
|
| |
|
|
|
|
|
|
|
|
| |
This patch adds support for two optimizations:
icmp ugt (udiv C2, X), C1 -> icmp ule X, C2/(C1+1)
icmp ult (udiv C2, X), C1 -> icmp ugt X, C2/C1
Differential Revision: http://reviews.llvm.org/D20123
llvm-svn: 269109
|
| |
|
|
|
|
|
| |
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/5103
Follow up from r269100.
llvm-svn: 269108
|
| |
|
|
|
|
|
|
| |
Usually subregister definitions are consider uses of the remaining
lanes that did not get defined. Add a comment why the code in
ScheduleDAGInstrs does not add use dependencies regardless.
llvm-svn: 269107
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Added support for extended mnemonics for the following branch instructions and
load/store-on-condition opcodes:
BR, LOCR, LOCGR, LOC, LOCG, STOC, STOCG
Phabricator: http://reviews.llvm.org/D19729
Committing on behalf of Zhan Liau
llvm-svn: 269106
|
| |
|
|
|
|
|
|
|
|
| |
With this patch:
%r1 = lshr i64 -1, 4294967296 -> undef
Before this patch:
%r1 = lshr i64 -1, 4294967296 -> 0
llvm-svn: 269105
|
| |
|
|
|
|
|
|
| |
Compiler-RT needs LLVM_LIBRARY_DIR, LLVM_BINARY_DIR.
Setting these in LLVMConfig.cmake will allow Compiler-RT to not need to run llvm-config as long as the LLVMConfig.cmake module is in the CMake module path.
llvm-svn: 269104
|
| |
|
|
|
|
|
|
|
|
|
|
| |
for the same subprogram.
This fixes a bug where DW_AT_abstract_origin is being emitted twice for
the same subprogram if a function is both inlined and emitted in the same
translation unit, by restoring the pre-r266446 behavior.
http://reviews.llvm.org/D20072
llvm-svn: 269103
|
| |
|
|
| |
llvm-svn: 269102
|
| |
|
|
|
|
|
|
|
|
|
| |
I'm really not sure why we were in the first place, it's the linker's job to
convert between BL/BLX as necessary. Even worse, using BLX left Thumb calls
that could be locally resolved completely unencodable since all offsets to BLX
are multiples of 4.
rdar://26182344
llvm-svn: 269101
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The way we currently build the internal VFS overlay representation leads
to inefficient path search and might yield wrong answers when asked for
recursive or regular directory iteration.
Currently, when reading an YAML file, each YAML root entry is placed
inside a new root in the filesystem overlay. In the crash reproducer, a
simple "@import Foundation" currently maps to 43 roots, and when looking
up paths, we traverse a directory tree for each of these different
roots, until we find a match (or don't). This has two consequences:
- It's slow.
- Directory iteration gives incomplete results since it only return
results within one root - since contents of the same directory can be
declared inside different roots, the result isn't accurate.
This is in part fault of the way we currently write out the YAML file
when emitting the crash reproducer - we could generate only one root and
that would make it fast and correct again. However, we should not rely
on how the client writes the YAML, but provide a good internal
representation regardless.
This patch builds a proper virtual directory tree out of the YAML
representation, allowing faster search and proper iteration. Besides the
crash reproducer, this potentially benefits other VFS clients.
llvm-svn: 269100
|
| |
|
|
|
|
| |
It didn't work on non-asserts builds
llvm-svn: 269099
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D20117
llvm-svn: 269098
|
| |
|
|
|
|
|
|
| |
The LoopPassManager needs to calculate the loops analysis in order to
iterate over the loops at all. Requiring it is redundant and just adds
noise to the RUN lines here.
llvm-svn: 269097
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An oddity of the .ll syntax is that the "@var = " in
@var = global i32 42
is optional. Writing just
global i32 42
is equivalent to
@0 = global i32 42
This means that there is a pretty big First set at the top level. The
current implementation maintains it manually. I was trying to refactor
it, but then started wondering why keep it a all. I personally find the
above syntax confusing. It looks like something is missing.
This patch removes the feature and simplifies the parser.
llvm-svn: 269096
|
| |
|
|
|
|
|
|
|
|
| |
reconstruct a compile unit or a function, but it still has a valid symbol - and it can use that in order to figure out the preferential language for lookups
This is not the right thing for all clients (notably the expression parser), so put it in type lookup specific code
Fixes rdar://problem/22422313
llvm-svn: 269095
|
| |
|
|
| |
llvm-svn: 269094
|
| |
|
|
|
|
|
|
|
| |
This patch extend loopreroll to allow the instruction chain
of loop control only IV has sext.
Differential Revision: http://reviews.llvm.org/D19820
llvm-svn: 269093
|