| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
| |
Also, add a scalar test to demonstrate one of the intermediate folds that
is necessary to accomplish the existing, multi-step test. And simplify
the vector tests to only check the final piece of that multi-step transform.
llvm-svn: 278995
|
| |
|
|
| |
llvm-svn: 278994
|
| |
|
|
| |
llvm-svn: 278992
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Duncan found that reverse worked on mutable rbegin(), but the has_rbegin
trait didn't work with a const method. See http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160815/382890.html
for more details.
Turns out this was already solved in clang with has_getDecl. Copied that and made it work for rbegin.
This includes the tests Duncan attached to that thread, including the traits test.
llvm-svn: 278991
|
| |
|
|
| |
llvm-svn: 278986
|
| |
|
|
|
|
|
|
| |
Since I stopped writing empty export tries it causes LinkEdit to potentially be completely empty which results in invalid yaml being generated.
To prevent this we skip linkedit data if it is empty.
llvm-svn: 278985
|
| |
|
|
|
|
| |
from r278970
llvm-svn: 278982
|
| |
|
|
|
|
|
|
| |
This will allow tail duplication and tail merging during layout to have a
shared threshold to make sure that they don't overlap. No observable change
intended.
llvm-svn: 278981
|
| |
|
|
|
|
|
| |
This will cause minsize functions to have the same threshold as optsize
functions, but otherwise should have no effects.
llvm-svn: 278980
|
| |
|
|
|
|
| |
and the mutation sequence
llvm-svn: 278975
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the undefined behaviour (UB) in ilist/ilist_node/etc.,
mainly by removing (gutting) the ilist_sentinel_traits customization
point and canonicalizing on a single, efficient memory layout. This
fixes PR26753.
The new ilist is a doubly-linked circular list.
- ilist_node_base has two ilist_node_base*: Next and Prev. Size-of: two
pointers.
- ilist_node<T> (size-of: two pointers) is a type-safe wrapper around
ilist_node_base.
- ilist_iterator<T> (size-of: two pointers) operates on an
ilist_node<T>*, and downcasts to T* on dereference.
- ilist_sentinel<T> (size-of: two pointers) is a wrapper around
ilist_node<T> that has some extra API for list management.
- ilist<T> (size-of: two pointers) has an ilist_sentinel<T>, whose
address is returned for end().
The new memory layout matches ilist_half_embedded_sentinel_traits<T>
exactly. The Head pointer that previously lived in ilist<T> is
effectively glued to the ilist_half_node<T> that lived in
ilist_half_embedded_sentinel_traits<T>, becoming the Next and Prev in
the ilist_sentinel_node<T>, respectively. sizeof(ilist<T>) is now the
size of two pointers, and there is never any additional storage for a
sentinel.
This is a much simpler design for a doubly-linked list, removing most of
the corner cases of list manipulation (add, remove, etc.). In follow-up
commits, I intend to move as many algorithms as possible into a
non-templated base class (ilist_base) to reduce code size.
Moreover, this fixes the UB in ilist_iterator/getNext/getPrev
operations. Previously, ilist_iterator<T> operated on a T*, even when
the sentinel was not of type T (i.e., ilist_embedded_sentinel_traits and
ilist_half_embedded_sentinel_traits). This added UB to all operations
involving end(). Now, ilist_iterator<T> operates on an ilist_node<T>*,
and only downcasts when the full type is guaranteed to be T*.
What did we lose? There used to be a crash (in some configurations) on
++end(). Curiously (via UB), ++end() would return begin() for users of
ilist_half_embedded_sentinel_traits<T>, but otherwise ++end() would
cause a nice dependable nullptr dereference, crashing instead of a
possible infinite loop. Options:
1. Lose that behaviour.
2. Keep it, by stealing a bit from Prev in asserts builds.
3. Crash on dereference instead, using the same technique.
Hans convinced me (because of the number of problems this and r278532
exposed on Windows) that we really need some assertion here, at least in
the short term. I've opted for #3 since I think it catches more bugs.
I added only a couple of unit tests to root out specific bugs I hit
during bring-up, but otherwise this is tested implicitly via the
extensive usage throughout LLVM.
Planned follow-ups:
- Remove ilist_*sentinel_traits<T>. Here I've just gutted them to
prevent build failures in sub-projects. Once I stop referring to them
in sub-projects, I'll come back and delete them.
- Add ilist_base and move algorithms there.
- Check and fix move construction and assignment.
Eventually, there are other interesting directions:
- Rewrite reverse iterators, so that rbegin().getNodePtr()==&*rbegin().
This allows much simpler logic when erasing elements during a reverse
traversal.
- Remove ilist_traits::createNode, by deleting the remaining API that
creates nodes. Intrusive lists shouldn't be creating nodes
themselves.
- Remove ilist_traits::deleteNode, by (1) asserting that lists are empty
on destruction and (2) changing API that calls it to take a Deleter
functor (intrusive lists shouldn't be in the memory management
business).
- Reconfigure the remaining callback traits (addNodeToList, etc.) to be
higher-level, pulling out a simple_ilist<T> that is much easier to
read and understand.
- Allow tags (e.g., ilist_node<T,tag1> and ilist_node<T,tag2>) so that T
can be a member of multiple intrusive lists.
llvm-svn: 278974
|
| |
|
|
|
|
|
|
|
|
| |
crashing"
This reverts commit r278967, since the new test is failing when you
don't build the WebAssembly target (most people, since it's
off-by-default).
llvm-svn: 278973
|
| |
|
|
|
|
|
|
| |
Making explicit our current policy to accept new targets as experimental and
later official. Every new target should follow these rules to be added,
and kept relevant in the upstream tree.
llvm-svn: 278971
|
| |
|
|
|
|
| |
Follow up to r278902. I had missed "fall through", with a space.
llvm-svn: 278970
|
| |
|
|
| |
llvm-svn: 278969
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Currently, enabling debug information when compiling for WebAssembly crashes the backend. This commit fixes these by skipping debug values in backend passes.
Reviewers: jfb, aprantl, dschuff, echristo
Subscribers: mehdi_amini, yurydelendik, dexonsmith, MatzeB, jfb, dschuff, llvm-commits
Differential Revision: https://reviews.llvm.org/D21808
llvm-svn: 278967
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is part of the "NodeType* -> NodeRef" migration. Notice that since
GraphWriter prints object address as identity, I added a static_assert on
NodeRef to be a pointer type.
Reviewers: dblaikie
Subscribers: llvm-commits, MatzeB
Differential Revision: https://reviews.llvm.org/D23580
llvm-svn: 278966
|
| |
|
|
| |
llvm-svn: 278965
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Looking at the implementation, GenericDomTree has more specific
requirements on NodeRef, e.g. NodeRefObject->getParent() should compile,
and NodeRef should be a pointer. We can remove the pointer requirement,
but it seems to have little gain, given the limited use cases.
Also changed GraphTraits<Inverse<Inverse<T>> to be more accurate.
Reviewers: dblaikie, chandlerc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D23593
llvm-svn: 278961
|
| |
|
|
| |
llvm-svn: 278960
|
| |
|
|
|
|
|
| |
Use m_APInt for the xor constant, but this is all still guarded by the initial
ConstantInt check, so no vector types should make it in here.
llvm-svn: 278957
|
| |
|
|
|
|
|
|
| |
1. Change variable names
2. Use local variables to reduce code
3. Early exit to reduce indent
llvm-svn: 278955
|
| |
|
|
|
|
|
|
|
|
|
| |
This is a fix for https://llvm.org/bugs/show_bug.cgi?id=29010
Root cause of the bug is that the register class of the machine instruction operand does not fully reflect if this registers that can be allocated.
Both for i386 and x86_64 the operand's register class is VR128RegClass and thus contains xmm0-xmm15, though in i386 we can only use xmm0-xmm8.
In order to get the actual allocable registers of the class we need to use RegisterClassInfo.
Differential Revision: https://reviews.llvm.org/D23613
llvm-svn: 278954
|
| |
|
|
| |
llvm-svn: 278950
|
| |
|
|
| |
llvm-svn: 278948
|
| |
|
|
|
|
|
|
|
|
| |
constant vectors
This is a sibling of:
https://reviews.llvm.org/rL278859
https://reviews.llvm.org/rL278935
llvm-svn: 278945
|
| |
|
|
|
|
|
|
|
| |
1. Change variable names
2. Use local variables to reduce code
3. Use ? instead of if/else
4. Use the APInt variable instead of 'RHS' so the removal of the FIXME code will be direct
llvm-svn: 278944
|
| |
|
|
| |
llvm-svn: 278943
|
| |
|
|
|
|
|
|
|
|
|
| |
This is used to mark functions with the C++11 [[ noreturn ]] or C11 _Noreturn
attributes.
Patch by Victor Leschuk!
https://reviews.llvm.org/D23167
llvm-svn: 278940
|
| |
|
|
|
|
|
|
| |
This reverts commit r258830, which introduced a bug described in PR28367.
PR28367
llvm-svn: 278938
|
| |
|
|
|
|
|
|
|
| |
constant vectors
This is a sibling of:
https://reviews.llvm.org/rL278859
llvm-svn: 278935
|
| |
|
|
|
|
|
|
|
| |
The statement on using #if 0 ... #endif is not very clear (for people like me
:-)). This patch clarifies it a bit to avoid confusion.
Differential Revision: https://reviews.llvm.org/D23404
llvm-svn: 278932
|
| |
|
|
|
|
|
|
| |
Reviewers: dsanders, vkalintiris
Differential Review: https://reviews.llvm.org/D23121
llvm-svn: 278930
|
| |
|
|
|
|
| |
This reverts commit r278928 due to lit test failures.
llvm-svn: 278929
|
| |
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D23464
PR28367
llvm-svn: 278928
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactored so that a LSRUse owns its fixups, as oppsed to letting the
LSRInstance own them. This makes it easier to rate formulas for
LSRUses, since the fixups are available directly. The Offsets vector
has been removed since it was no longer necessary.
New target hook isFoldableMemAccessOffset(), which is used during formula
rating.
For SystemZ, this is useful to express that loads and stores with
float or vector types with a big/negative offset should be avoided in
loops. Without this, LSR will generate a lot of negative offsets that
would require extra instructions for loading the address.
Updated tests:
test/CodeGen/SystemZ/loop-01.ll
Reviewed by: Quentin Colombet and Ulrich Weigand.
https://reviews.llvm.org/D19152
llvm-svn: 278927
|
| |
|
|
|
|
|
|
|
|
| |
In theory the indices of RC (and thus the index used for LiveRegs) may differ from the indices of OpRC.
Fixed the code to extract the correct RC index.
OpRC contains the first X consecutive elements of RC, and thus their indices are currently de facto the same, therefore a test cannot be added at this point.
Differential Revision: https://reviews.llvm.org/D23491
llvm-svn: 278923
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
symbol.
Summary: This change fix bug in AMDGPU disassembly. Previously, presence of symbols other than kernel symbols caused objdump to skip begining of those symbols.
Reviewers: tstellarAMD, vpykhtin, Bigcheese, ruiu
Subscribers: kzhuravl, arsenm
Differential Revision: http://reviews.llvm.org/D21966
llvm-svn: 278921
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
See D22198 for the motivation: We have a pass that uses LiveIntervals anyway,
and there is now a requirement to track a physical register that is not
usually tracked at this point of the compilation. The pass also introduces
instructions that affect this physical register, but we want to preserve
LiveIntervals.
Rather than add brittle and rarely exercised code to keep the tracking of
the physical register intact, we want to just remove the corresponding
LiveRange -- it didn't exist before anyway, and subsequent passes don't
expect it to be there.
Reviewers: MatzeB, arsenm
Subscribers: llvm-commits, MatzeB
Differential Revision: https://reviews.llvm.org/D22801
llvm-svn: 278920
|
| |
|
|
|
|
|
| |
Replacing the usage of MVT with EVT in case the vector type is expanded.
Differential Revision: https://reviews.llvm.org/D23306
llvm-svn: 278913
|
| |
|
|
|
|
|
|
|
| |
The ASan build bot caught this right away:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/15580/steps/check-llvm%20asan/logs/stdio
This was also breaking a Windows build bot I'm pretty sure.
llvm-svn: 278912
|
| |
|
|
| |
llvm-svn: 278910
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
can given the current __cplusplus definitions).
Without this, Clang triggers TONS of warnings about using a C++17
extension. I tried using LLVM_EXTENSION to turn these off and it doesn't
work.
Suggestions on a better approach are welcome, but at least this makes
the build usable for me again.
llvm-svn: 278909
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
While NFC for now, this will allow more flexibility on the client side
to hold state necessary to back up the stream.
Also when adding caching, this class will grow in complexity.
Note I blindly modified the gold-plugin as I can't compile it.
Reviewers: tejohnson
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D23542
llvm-svn: 278907
|
| |
|
|
|
|
|
| |
I was over-aggressive in my conversions from comments to the
fallthrough attribute.
llvm-svn: 278903
|
| |
|
|
|
|
|
| |
This is a mechanical change of comments in switches like fallthrough,
fall-through, or fall-thru to use the LLVM_FALLTHROUGH macro instead.
llvm-svn: 278902
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a quick work around, because in some cases, e.g. caller's stack
size > callee's stack size, we are still able to apply sibling call
optimization even callee has any byval arg.
This patch fix: https://llvm.org/bugs/show_bug.cgi?id=28328
Reviewers: hfinkel kbarton nemanjai amehsan
Subscribers: hans, tjablin
https://reviews.llvm.org/D23441
llvm-svn: 278900
|
| |
|
|
|
|
|
|
| |
Now the tests of TargetParser is in place:
unittests/Support/TargetParserTest.cpp.
So the tests in TripleTest.cpp which actually stressing TargetParser's behavior could be removed.
llvm-svn: 278899
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
minimal and boring form than the old pass manager's version.
This pass does the very minimal amount of work necessary to inline
functions declared as always-inline. It doesn't support a wide array of
things that the legacy pass manager did support, but is alse ... about
20 lines of code. So it has that going for it. Notably things this
doesn't support:
- Array alloca merging
- To support the above, bottom-up inlining with careful history
tracking and call graph updates
- DCE of the functions that become dead after this inlining.
- Inlining through call instructions with the always_inline attribute.
Instead, it focuses on inlining functions with that attribute.
The first I've omitted because I'm hoping to just turn it off for the
primary pass manager. If that doesn't pan out, I can add it here but it
will be reasonably expensive to do so.
The second should really be handled by running global-dce after the
inliner. I don't want to re-implement the non-trivial logic necessary to
do comdat-correct DCE of functions. This means the -O0 pipeline will
have to be at least 'always-inline,global-dce', but that seems
reasonable to me. If others are seriously worried about this I'd like to
hear about it and understand why. Again, this is all solveable by
factoring that logic into a utility and calling it here, but I'd like to
wait to do that until there is a clear reason why the existing
pass-based factoring won't work.
The final point is a serious one. I can fairly easily add support for
this, but it seems both costly and a confusing construct for the use
case of the always inliner running at -O0. This attribute can of course
still impact the normal inliner easily (although I find that
a questionable re-use of the same attribute). I've started a discussion
to sort out what semantics we want here and based on that can figure out
if it makes sense ta have this complexity at O0 or not.
One other advantage of this design is that it should be quite a bit
faster due to checking for whether the function is a viable candidate
for inlining exactly once per function instead of doing it for each call
site.
Anyways, hopefully a reasonable starting point for this pass.
Differential Revision: https://reviews.llvm.org/D23299
llvm-svn: 278896
|
| |
|
|
|
|
| |
Also put some commonly used subexpressions into variables.
llvm-svn: 278895
|