| Commit message (Collapse) | Author | Age | Files | Lines | 
| | 
| 
| 
| 
| 
| 
|  | 
It makes sense to only do them once in IRTranslator rather than making everyone
deal with them.
llvm-svn: 297304
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Analyzing larger trees is extremely difficult with the current debug output so
this adds GraphTraits and DOTGraphTraits on top of the VectorizableTree data
structure.  We can now display the SLP trees with Graphviz as in
https://reviews.llvm.org/F3132765.
I decorated the graph where a value needs to be gathered for one reason or
another.  These are the red nodes.
There are other improvement I am planning to make as I work through my case
here.  For example, I would also like to mark nodes that need to be extracted.
Differential Revision: https://reviews.llvm.org/D30731
llvm-svn: 297303
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Because IRBuilder performs constant-folding, it's not guaranteed that an
instruction in the original loop map to an instruction in the vector loop. It
could map to a constant vector instead. The handling of first-order recurrences
was incorrectly making this assumption when setting the IRBuilder's insert
point.
llvm-svn: 297302
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary: rL297171 introduced G_FNEG for floating-point negation instruction and IRTranslator started to translate `FSUB -0.0, X` to `FNEG X`. This patch adds a default action for G_FNEG to avoid breaking existing targets.
Reviewers: qcolombet, ab, kristof.beyls, t.p.northover, aditya_nandakumar, dsanders
Reviewed By: qcolombet
Subscribers: dberris, rovka, llvm-commits
Differential Revision: https://reviews.llvm.org/D30721
llvm-svn: 297301
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This was originall reverted due to some test failures in
ModuleCache and TestCompDirSymlink.  These issues have all
been resolved and the code now passes all tests.
Differential Revision: https://reviews.llvm.org/D30698
llvm-svn: 297300
 | 
| | 
| 
| 
| 
| 
| 
|  | 
This test could be reduced? The check fails for a seemingly unrelated change,
so I'm adding full checks to see what is happening.
llvm-svn: 297296
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
This patch also renames the PR number the test points to. The previous
reference was PR29559, but that bug was somehow deleted and recreated under
PR30183.
llvm-svn: 297295
 | 
| | 
| 
| 
|  | 
llvm-svn: 297294
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
When extracting a bitfield from the high register in a register pair,
the final offset should be relative to the high register (for 32-bit
extracts).
llvm-svn: 297288
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary: By using reg_nodbg_empty() to determine if a function can be
treated as a leaf function or not, we miss the case when the register
pair L0_L1 is used but not L0 by itself. This has the effect that
use_all_i32_regs(), a test in reserved-regs.ll which tries to use all
registers, gets treated as a leaf function.
Reviewers: jyknight, venkatra
Reviewed By: jyknight
Subscribers: davide, RKSimon, sepavloff, llvm-commits
Differential Revision: https://reviews.llvm.org/D27089
llvm-svn: 297285
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary: Use AA when scanning to find an available load value.
Reviewers: rengolin, mcrosier, hfinkel, trentxintong, dberlin
Reviewed By: rengolin, dberlin
Subscribers: aemerson, dberlin, llvm-commits
Differential Revision: https://reviews.llvm.org/D30352
llvm-svn: 297284
 | 
| | 
| 
| 
| 
| 
|  | 
same as result type
llvm-svn: 297280
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
On Windows stderr and stdout happen to get interleaved in a way that causes the
test to fail, so split it up into a test that checks for errors and a test that
doesn't.
llvm-svn: 297273
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Recommitting patch which was previously reverted in r297159. These
changes should address the casting issues.
The original patch enables dbg.value intrinsics to be attached to
newly inserted PHI nodes.
Differential Review: https://reviews.llvm.org/D30701
llvm-svn: 297269
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
elements wide
By defining the mask types as SmallVector<int, 16> we were causing a lot of unnecessary heap usage.
llvm-svn: 297267
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
rL295768 introduced this test that fails if LLVM is built and tested on
an NFS share. Delete the test as discussed on the corresponing commit
thread. The only feasible solution would have been to introduce
environment variables and to en/disable the test conditionally.
llvm-svn: 297260
 | 
| | 
| 
| 
| 
| 
|  | 
Differential Revision: https://reviews.llvm.org/D30638
llvm-svn: 297257
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
reduce stack frame size""
After inspection, it's an UB in our code base. Someone cast a var-arg
function pointer to a non-var-arg one. :/
Re-commit r296771 to continue testing on the patch.
Sorry for the trouble!
llvm-svn: 297256
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
MSVC 2017 was released today, and I found one bug in the
compiler which prevents a successful build of LLVM.  This
patch works around the bug in a fairly benign way.
llvm-svn: 297255
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
A block with an UnreachableInst does not transfer execution to a successor.
The problem was exposed by GVN-hoist. This patch fixes bug 32153.
Patch by Aditya Kumar.
Differential Revision: https://reviews.llvm.org/D30667
llvm-svn: 297254
 | 
| | 
| 
| 
| 
| 
|  | 
There's no need to have two separate APIs.
llvm-svn: 297253
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
isImageReadWrite calls
This is repetition of isImage() function in NVPTXUtilities.cpp.
Patch by Briana Grace!
Differential Revision: https://reviews.llvm.org/D30706
llvm-svn: 297252
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
If there is only one successor, and that successor only
has one predecessor the wait can obviously be delayed until
uses or the end of the next block. This avoids code quality
regressions when there are trivial fallthrough blocks inserted
for structurization.
llvm-svn: 297251
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
This helps in cases involving bitfields where an AND is exposed by
legalization.
Differential Revision: https://reviews.llvm.org/D30472
llvm-svn: 297249
 | 
| | 
| 
| 
| 
| 
| 
|  | 
When doing arcp optimization with a constant denominator,
this was leaving behind rcps with constant inputs.
llvm-svn: 297248
 | 
| | 
| 
| 
| 
| 
|  | 
Differential Revision: https://reviews.llvm.org/D29672
llvm-svn: 297247
 | 
| | 
| 
| 
| 
| 
|  | 
It was added between my build+test and my commit.
llvm-svn: 297244
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Reviewers:
  arsenm
Differential Revision:
  http://reviews.llvm.org/D22025
llvm-svn: 297243
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This is the 2nd part of solving:
http://lists.llvm.org/pipermail/llvm-dev/2017-February/110293.html
D30123 moves the trunc ahead of the shuffle, and this moves the trunc ahead of the insertelement. 
We're limiting this transform to undef rather than any constant to avoid backend problems.
Differential Revision: https://reviews.llvm.org/D30137
llvm-svn: 297242
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
object that knows how to generate it.
Summary:
This will allow future patches to inspect the details of the LLT. The implementation is now split between
the Support and CodeGen libraries to allow TableGen to use this class without introducing layering concerns.
Thanks to Ahmed Bougacha for finding a reasonable way to avoid the layering issue and providing the version of this patch without that problem.
The problem with the previous commit appears to have been that TableGen was including CodeGen/LowLevelType.h instead of Support/LowLevelTypeImpl.h.
Reviewers: t.p.northover, qcolombet, rovka, aditya_nandakumar, ab, javed.absar
Subscribers: arsenm, nhaehnle, mgorny, dberris, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D30046
llvm-svn: 297241
 | 
| | 
| 
| 
|  | 
llvm-svn: 297240
 | 
| | 
| 
| 
|  | 
llvm-svn: 297239
 | 
| | 
| 
| 
|  | 
llvm-svn: 297237
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Itanium ABI may have an address point one byte after the end of a
vtable. When such vtable global is split, the !type metadata needs to
follow the right vtable.
Differential Revision: https://reviews.llvm.org/D30716
llvm-svn: 297236
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Fix SmallPtrSet::iterator behaviour and creation ReverseIterate is true.
  - Any function that creates an iterator now uses
    SmallPtrSet::makeIterator, which creates an iterator that
    dereferences to the given pointer.
  - In reverse-iterate mode, initialze iterator::End with "CurArray"
    instead of EndPointer.
  - In reverse-iterate mode, the current node is iterator::Buffer[-1].
    iterator::operator* and SmallPtrSet::makeIterator are the only ones
    that need to know.
  - Fix the assertions for reverse-iterate mode.
This fixes the tests Danny B added in r297182, and adds a couple of
others to confirm that dereferencing does the right thing, regardless of
how the iterator was found, and that iteration works correctly from each
return from find.
llvm-svn: 297234
 | 
| | 
| 
| 
|  | 
llvm-svn: 297233
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This was committed at r297155 and reverted at r297166 because of an
over-reaching clang test. That should be fixed with r297189.
This is one part of solving a recent bug report:
http://lists.llvm.org/pipermail/llvm-dev/2017-February/110293.html
This keeps with our general approach: changing arbitrary shuffles is off-limts,
but changing splat is ok. The transform is very similar to the existing
shrinkBitwiseLogic() canonicalization.
Differential Revision: https://reviews.llvm.org/D30123
llvm-svn: 297232
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
In my refactoring I introduced a bug where we were using the reference size instead of the offset size for DW_FORM_strp and similar forms.
This patch resolves the error and adds a test case testing all the DWARF forms for DWARF2 AddrSize 8. There is similar coverage already in the DWARFDebugInfoTest sources that covers the parser. Once I migrate the DWARFGenerator APIs to be built on the YAML tools they will be fully covered under the same tests.
llvm-svn: 297230
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
We were calculating incorrect extract/insert offsets by trying to be too
tricksy with min/max. It's clearer to just split the logic up into "register
starts before this segment" vs "after".
llvm-svn: 297226
 | 
| | 
| 
| 
|  | 
llvm-svn: 297225
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary:
The purpose of coro.end intrinsic is to allow frontends to mark the cleanup and
other code that is only relevant during the initial invocation of the coroutine
and should not be present in resume and destroy parts.
In landing pads coro.end is replaced with an appropriate instruction to unwind to
caller. The handling of coro.end differs depending on whether the target is
using landingpad or WinEH exception model.
For landingpad based exception model, it is expected that frontend uses the
`coro.end`_ intrinsic as follows:
```
    ehcleanup:
      %InResumePart = call i1 @llvm.coro.end(i8* null, i1 true)
      br i1 %InResumePart, label %eh.resume, label %cleanup.cont
    cleanup.cont:
      ; rest of the cleanup
    eh.resume:
      %exn = load i8*, i8** %exn.slot, align 8
      %sel = load i32, i32* %ehselector.slot, align 4
      %lpad.val = insertvalue { i8*, i32 } undef, i8* %exn, 0
      %lpad.val29 = insertvalue { i8*, i32 } %lpad.val, i32 %sel, 1
      resume { i8*, i32 } %lpad.val29
```
The `CoroSpit` pass replaces `coro.end` with ``True`` in the resume functions,
thus leading to immediate unwind to the caller, whereas in start function it
is replaced with ``False``, thus allowing to proceed to the rest of the cleanup
code that is only needed during initial invocation of the coroutine.
For Windows Exception handling model, a frontend should attach a funclet bundle
referring to an enclosing cleanuppad as follows:
```
    ehcleanup:
      %tok = cleanuppad within none []
      %unused = call i1 @llvm.coro.end(i8* null, i1 true) [ "funclet"(token %tok) ]
      cleanupret from %tok unwind label %RestOfTheCleanup
```
The `CoroSplit` pass, if the funclet bundle is present, will insert
``cleanupret from %tok unwind to caller`` before
the `coro.end`_ intrinsic and will remove the rest of the block.
Reviewers: majnemer
Reviewed By: majnemer
Subscribers: llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D25543
llvm-svn: 297223
 | 
| | 
| 
| 
|  | 
llvm-svn: 297222
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
Some intrinsics take metadata parameters.  These all need custom
handling of some form, and cannot possibly be lowered generically to
G_INTRINSIC calls with vreg operands.
Reject them, instead of hitting an assert later in getOrCreateVReg.
llvm-svn: 297209
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
When we translate a no-op (same type) bitcast, we try to be clever and
only emit a COPY if we already assigned a vreg to the defined value.
However, when we didn't, we tried to assign to a reference into the
ValToVReg DenseMap, even though the RHS of the assignment
(getOrCreateVReg) could potentially grow that DenseMap, invalidating the
reference.
Avoid that by getting the source vreg first.
I audited the rest of the translator; this is the only tricky case.
The test is quite unwieldy, as the problem is caused by the DenseMap
growing, which happens after the 47th mapped value.
llvm-svn: 297208
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
For vector operands, the `select` instruction supports both vector and
non-vector conditions.  The MIR builder had an overly restrictive
assertion, that only accepted vector conditions for vector selects
(in effect implementing ISD::VSELECT).
Make it possible to express the full range of G_SELECTs.
llvm-svn: 297207
 | 
| | 
| 
| 
|  | 
llvm-svn: 297206
 | 
| | 
| 
| 
| 
| 
| 
|  | 
I messed up my rebases leading to r297200, and ended up with stale (but
working) code.  Fix it.
llvm-svn: 297205
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Reviewers: kcc
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D30682
llvm-svn: 297202
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
When computing the mapping for non-generic instructions, we skipped
%noreg operands, because we can't always reason about their banks.
Also skip them when applying the mapping.  Otherwise, we could end
up with mappings that we can't apply.
While there, duplicate an assert to distinguish between the two
error conditions.
llvm-svn: 297201
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
When a dbg_value has a constant operand that isn't representable in MI,
there isn't much we can do.  Use %noreg (0) for those situations.
This matches the SelectionDAG behavior.
llvm-svn: 297200
 |