| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 208145
|
| |
|
|
|
|
|
|
| |
Previously only the toplevel elements were expanded by expandElements().
Now we recursively call getReplacements() to expand input elements even
if they are in, say, in a group.
llvm-svn: 208144
|
| |
|
|
|
|
| |
This can happen in practice with the user changing files and we can recover from it.
llvm-svn: 208143
|
| |
|
|
|
|
| |
which is a more correct and consistent term.
llvm-svn: 208142
|
| |
|
|
| |
llvm-svn: 208141
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Update our mangling to match the discussion on cxx-abi-dev.
This involves using a seq-id instead of an optional number.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3631
llvm-svn: 208140
|
| |
|
|
|
|
|
|
| |
This is similar to the getAlignment patch, but is done just for
completeness. It looks like we never call getSection on an alias. All the
tests still pass if the if is replaced with an assert.
llvm-svn: 208139
|
| |
|
|
| |
llvm-svn: 208138
|
| |
|
|
| |
llvm-svn: 208137
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace a large monolitic function, with per-table functions which all nicely
fit on my screen. I also added documentation to each function that describes
what kind of tables are generated and which information is contained and
switched to range based for loops. Finally, I run clang-format over the moved
code.
I spent a significant amount of time to understand this code when reasoning
about possible extensions to the diagnostic interface to support 'remark'
diagnostics. This change will definitely help such an implementation, but
already by itself it will save other people a lot of time when trying to
understand this functionality.
Even though the patch touches the full function, it is mostly mechanical. No
functional change intended. The generated tblgen files are identical.
llvm-svn: 208136
|
| |
|
|
|
|
| |
http://reviews.llvm.org/D3386
llvm-svn: 208135
|
| |
|
|
| |
llvm-svn: 208132
|
| |
|
|
|
|
|
|
|
| |
Speculatively reverting due to a suspicious failure on a Windows
buildbot.
This reverts commit 10c37a012ea11596d44cd9059fe09c959caf30c8.
llvm-svn: 208131
|
| |
|
|
| |
llvm-svn: 208130
|
| |
|
|
|
|
|
|
| |
remove it from the list of unspilled registers. Otherwise the following
attempt to keep the stack aligned by picking an extra GPR register to
spill will not work as it picks up r11.
llvm-svn: 208129
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes it easier to see where a global ctor comes from, and it also makes
ASan's init order analyzer output easier to understand. gcc does this too,
but only in -fPIC mode for some reason. Don't do this for constructors with
explicit init priority.
Also prepend "sub_" before the 'I', that way regular constructors stay
lexicographically after symbols with init priority (because
ord('s') > ord('I')). gold seems to ignore the name of constructor symbols,
and ld only looks at the symbol if it includes an init priority, which this
patch doesn't change.
Before: __GLOBAL_I_a
Now: __GLOBAL_sub_I_myfile.cc
llvm-svn: 208128
|
| |
|
|
|
|
|
|
| |
This removes arguments passed everywhere and allows the use of
standard iteration over lists.
Should be no functional change.
llvm-svn: 208127
|
| |
|
|
|
|
|
| |
Split from the musttail inliner change. This will be covered by an opt
test when the inliner change lands.
llvm-svn: 208126
|
| |
|
|
| |
llvm-svn: 208124
|
| |
|
|
| |
llvm-svn: 208123
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When I initially introduced -pass-remarks, I thought it would be a
neat idea to make it additive. So, if one used it as:
$ llc -pass-remarks=inliner --pass-remarks=loop.*
the compiler would build the regular expression '(inliner)|(loop.*)'.
The more I think about it, the more I regret it. This is not how
other flags work. The standard semantics are right-to-left overrides.
This is how clang interprets -Rpass. And I think the two should be
compatible in this respect.
Reviewers: qcolombet
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D3614
llvm-svn: 208122
|
| |
|
|
| |
llvm-svn: 208121
|
| |
|
|
| |
llvm-svn: 208120
|
| |
|
|
| |
llvm-svn: 208119
|
| |
|
|
| |
llvm-svn: 208118
|
| |
|
|
|
|
|
|
| |
MacOSX.
<rdar://problem/16822217>
llvm-svn: 208117
|
| |
|
|
| |
llvm-svn: 208116
|
| |
|
|
|
|
| |
the target.
llvm-svn: 208115
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
preceeds the declaration and initial use.
Reverting r208106 to reapply r208065 with a fix for the regression. The
issue was that the enum tried to be built even if the declaration hadn't
been constructed for debug info - presenting problems for enum templates
and typedefs of enums with names for linkage purposes.
Original commit message:
This regressed a little further 208055 though it was already a little
broken.
While the requiresCompleteType optimization should be implemented here.
Future (possibly near future) work.
llvm-svn: 208114
|
| |
|
|
| |
llvm-svn: 208112
|
| |
|
|
| |
llvm-svn: 208111
|
| |
|
|
|
|
|
|
| |
BugReport doesn't take ownership of the bug type, so let the checker own the
the bug type. (Requires making the bug type mutable, which is icky, but which
is also what other checkers do.)
llvm-svn: 208110
|
| |
|
|
|
|
|
| |
addInputElement() never fails, and no one checks its return value
except tests. Let's simplify the signature.
llvm-svn: 208109
|
| |
|
|
|
|
|
|
|
| |
(I tried converting StateMapsArray to a vector<unique_ptr> and changing the
types of getInfo() and addInfo() to take unique_ptrs. This mostly worked,
except for the three-argument form of addInfo() which I found confusing enough
that I went with this simpler fix for now.)
llvm-svn: 208108
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(and vice versa).
Before this patch, the backend always emitted a store+load sequence to
bitconvert from f64 to i64 the input operand of a ISD::BITCAST dag node that
performed a bitconvert from type MVT::f64 to type MVT::v2i32. The resulting
i64 node was then used to build a v2i32 vector.
With this patch, the backend now produces a cheaper SCALAR_TO_VECTOR from
MVT::f64 to MVT::v2f64. That SCALAR_TO_VECTOR is then followed by a "free"
bitcast to type MVT::v4i32. The elements of the resulting
v4i32 are then extracted to build a v2i32 vector (which is illegal and
therefore promoted to MVT::v2i64).
This is in general cheaper than emitting a stack store+load sequence
to bitconvert the operand from type f64 to type i64.
llvm-svn: 208107
|
| |
|
|
|
|
|
|
|
|
|
| |
the declaration and initial use."
This is breaking the compiler-rt build. Reverting while I
investigate/fix.
This reverts commit r208065.
llvm-svn: 208106
|
| |
|
|
|
|
| |
Reviewed by Eric Christopher.
llvm-svn: 208105
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch implements the infrastructure to use named register constructs in
programs that need access to specific registers (bare metal, kernels, etc).
So far, only the stack pointer is supported as a technology preview, but as it
is, the intrinsic can already support all non-allocatable registers from any
architecture.
llvm-svn: 208104
|
| |
|
|
|
|
|
|
|
| |
An alias has the address of what it points to, so it also has the same
alignment.
This allows a few optimizations to see past aliases for free.
llvm-svn: 208103
|
| |
|
|
|
|
|
|
| |
fall back to the normal path without a cpu. While doing this fix
llc to just exit when we don't have a module to process instead of
asserting.
llvm-svn: 208102
|
| |
|
|
| |
llvm-svn: 208101
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 208099
|
| |
|
|
| |
llvm-svn: 208098
|
| |
|
|
|
|
| |
were subtly invalid (didn't compare equal). Thanks to Erik Verbruggen for the report (and diagnosis)
llvm-svn: 208096
|
| |
|
|
| |
llvm-svn: 208095
|
| |
|
|
|
|
|
| |
The fact that GlobalAlias::setAlignment exists at all is a side effect of
how the classes are organized, it should never be used.
llvm-svn: 208094
|
| |
|
|
|
|
|
|
|
|
| |
Before:
var x = /** @type {foo} */ (bar);
After:
var x = /** @type {foo} */(bar);
llvm-svn: 208093
|
| |
|
|
|
|
| |
to verify annotations in vector-like containers
llvm-svn: 208092
|
| |
|
|
| |
llvm-svn: 208091
|
| |
|
|
| |
llvm-svn: 208090
|