| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 281865
|
| |
|
|
| |
llvm-svn: 281862
|
| |
|
|
|
|
| |
conversion intrinsics to be consistent across all intruction sets.
llvm-svn: 281861
|
| |
|
|
|
|
| |
correct register class.
llvm-svn: 281860
|
| |
|
|
| |
llvm-svn: 281859
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D23727
llvm-svn: 281858
|
| |
|
|
|
|
|
|
|
| |
Amended consecutive memory access detection in Loop Vectorizer.
Load/Store were not handled properly without preceding GEP instruction.
Differential Revision: https://reviews.llvm.org/D20789
llvm-svn: 281853
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
as sitofp
With D24253 we can now use SelectionDAG::SignBitIsZero with vector operations.
This patch uses SelectionDAG::SignBitIsZero to recognise that a zero sign bit means that we can use a sitofp instead of a uitofp (which is not directly support on pre-AVX512 hardware).
While AVX512 does provide support for uitofp, the conversion to sitofp should not cause any regressions.
Differential Revision: https://reviews.llvm.org/D24343
llvm-svn: 281852
|
| |
|
|
|
|
|
|
|
| |
Simplified GEP cloning in vectorizeMemoryInstruction().
Added an assertion that checks consecutive GEP, which should have only one loop-variant operand.
Differential Revision: https://reviews.llvm.org/D24557
llvm-svn: 281851
|
| |
|
|
|
|
|
| |
It is a trivial change which could make the testcase easier to be reused
for the store splitting in CodeGenPrepare.
llvm-svn: 281846
|
| |
|
|
|
|
| |
the guard type to intptr_t; use separate array for 8-bit counters
llvm-svn: 281845
|
| |
|
|
| |
llvm-svn: 281843
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes an issue when files are compiled with -flto=thin
at default -O0. We need to rename anonymous globals before attempting
to write the module summary because all values need names for
the summary. This was happening at -O1 and above, but not before
the early exit when constructing the pipeline for -O0.
Also add an internal -prepare-for-thinlto option to enable this
to be tested via opt.
Fixes PR30419.
Reviewers: mehdi_amini
Subscribers: probinson, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D24701
llvm-svn: 281840
|
| |
|
|
|
|
| |
Add ability to extract vXi64 'vzext_movl' masks on 32-bit targets
llvm-svn: 281834
|
| |
|
|
|
|
| |
Added BoundaryNode check to isBestZeroLatency function.
llvm-svn: 281825
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were trying to avoid using a FrameIndex operand in non-pointer
operands in a convoluted way, and would break because of
using TargetFrameIndex. The TargetFrameIndex should only be used
in the case where it makes sense to fold it as part of the addressing
mode, otherwise it requires materialization like a normal constant.
This wasn't working reliably and failed in the added testcase, hitting
the assert when processing the frame index.
The TargetFrameIndex was coming from trying to produce an AssertZext
limiting the maximum stack size. I'm not sure this was correct to begin
with, because it is apparently possible to have a single workitem
dispatch that requires all 4G of private memory.
llvm-svn: 281824
|
| |
|
|
| |
llvm-svn: 281823
|
| |
|
|
|
|
|
|
| |
This reduces the number of copies and reg_sequences
when using fp constant vectors. This significantly
reduces the code size in local-stack-alloc-bug.ll
llvm-svn: 281822
|
| |
|
|
|
|
| |
to fix check-fuzzer on the bot
llvm-svn: 281814
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
names (NFC)
The ValueSymbolTable is used to detect name conflict and rename
instructions automatically. This is not needed when the value
names are automatically discarded by the LLVMContext.
No functional change intended, just saving a little bit of memory.
This is a recommit of r281806 after fixing the accessor to return
a pointer instead of a reference and updating all the call-sites.
llvm-svn: 281813
|
| |
|
|
|
|
| |
Last-second refactoring before push was bad idea...
llvm-svn: 281812
|
| |
|
|
|
|
| |
This is in line with the LLParser behavior
llvm-svn: 281811
|
| |
|
|
| |
llvm-svn: 281810
|
| |
|
|
| |
llvm-svn: 281809
|
| |
|
|
|
|
|
|
|
| |
value names (NFC)"
This reverts commit r281806. It introduces undefined behavior as an
API is returning a reference to the Symtab
llvm-svn: 281808
|
| |
|
|
|
|
|
|
|
|
|
| |
names (NFC)
The ValueSymbolTable is used to detect name conflict and rename
instructions automatically. This is not needed when the value
names are automatically discarded by the LLVMContext.
No functional change intended, just saving a little bit of memory.
llvm-svn: 281806
|
| |
|
|
|
|
| |
VI added eq/ne for i64, so use them.
llvm-svn: 281800
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: i8, i16, and f16 values are not extended to 32-bit in the HSA kernel ABI.
Reviewers: arsenm
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, llvm-commits, yaxunl
Differential Revision: https://reviews.llvm.org/D24621
llvm-svn: 281789
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
shuffle
As discussed on llvm-dev ( http://lists.llvm.org/pipermail/llvm-dev/2016-August/104210.html ):
turn a vector select with constant condition operand into a shuffle as a canonicalization step.
Shuffles may be easier to reason about in conjunction with other shuffles and insert/extract.
Possible known (minor?) regressions from this change are filed as:
https://llvm.org/bugs/show_bug.cgi?id=28530
https://llvm.org/bugs/show_bug.cgi?id=28531
https://llvm.org/bugs/show_bug.cgi?id=30371
If something terrible happens to perf after this commit, feel free to revert until a backend
fix is in place.
Differential Revision: https://reviews.llvm.org/D24279
llvm-svn: 281787
|
| |
|
|
|
|
|
|
|
|
|
| |
These clean up some unnecessary or instructions in
cases with complex loops.
In the original testcase I noticed this, the same
or with exec was repeated 5 or 6 times in a row. With
this only one is emitted or sometimes a copy.
llvm-svn: 281786
|
| |
|
|
|
|
|
|
|
|
| |
This is a fix for PR30318.
Clang may generate IR where an alloca is already live when entering a
BB with lifetime.start. In this case, conservatively extend the
alloca lifetime all the way back to the block entry.
llvm-svn: 281784
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When trying to recolor a register we may split live-ranges in the
process. When we create new live-ranges we will have to process them,
but when we move a register from Assign to Split, the allocation is not
changed until the whole recoloring session is successful.
Therefore, only push the live-ranges that changed from Assign to
Split when the recoloring is successful.
Same as the previous commit, I was not able to produce a test case that
reproduce the problem with in-tree targets.
Note: The bug has been here since the recoloring scheme has been added
back in r200883 (Feb 2014).
llvm-svn: 281783
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is used.
When last chance recoloring is used, the list of NewVRegs may not be
empty when calling selectOrSplitImpl. Indeed, another coloring may have
taken place with splitting/spilling in the same recoloring session.
Relax an assertion to take this into account and adapt a condition to
act as if the NewVRegs were local to this selectOrSplitImpl instance.
Unfortunately I am unable to produce a test case for this, I was only
able to reproduce the conditions on an out-of-tree target.
llvm-svn: 281782
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The main challenge in lowering kernel arguments for AMDGPU is determing the
memory type of the argument. The generic calling convention code assumes
that only legal register types can be stored in memory, but this is not the
case for AMDGPU.
This consolidates all the logic AMDGPU uses for deducing memory types into a single
function. This will make it much easier to support different ABIs in the future.
Reviewers: arsenm
Subscribers: arsenm, wdng, nhaehnle, llvm-commits, yaxunl
Differential Revision: https://reviews.llvm.org/D24614
llvm-svn: 281781
|
| |
|
|
| |
llvm-svn: 281780
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
mesa3d will use the same kernel calling convention as amdhsa, but it will
handle everything else like the default 'unknown' OS type.
Reviewers: arsenm
Subscribers: arsenm, llvm-commits, kzhuravl
Differential Revision: https://reviews.llvm.org/D22783
llvm-svn: 281779
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(PR24942)
computeKnownBits() already works for integer vectors, so allow vector types when calling that from InstCombine.
I don't think the change to use m_APInt in computeKnownBits is strictly necessary because we do check for
ConstantVector later, but it's more efficient to handle the splat case without needing to loop on vector elements.
This should work with InstSimplify, but doesn't yet, so I made that a FIXME comment on the test for PR24942:
https://llvm.org/bugs/show_bug.cgi?id=24942
Differential Revision: https://reviews.llvm.org/D24677
llvm-svn: 281777
|
| |
|
|
|
|
|
| |
This is supposed to be a drop in replacement for what lld
provides via --lto-newpm-aa-pipeline.
llvm-svn: 281774
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Recommitting after fixing AsmParser initialization and X86 inline asm
error cleanup.
Allow errors to be deferred and emitted as part of clean up to simplify
and shorten Assembly parser code. This will allow error messages to be
emitted in helper functions and be modified by the caller which has
better context.
As part of this many minor cleanups to the Parser:
* Unify parser cleanup on error
* Add Workaround for incorrect return values in ParseDirective instances
* Tighten checks on error-signifying return values for parser functions
and fix in-tree TargetParsers to be more consistent with the changes.
* Fix AArch64 test cases checking for spurious error messages that are
now fixed.
These changes should be backwards compatible with current Target Parsers
so long as the error status are correctly returned in appropriate
functions.
Reviewers: rnk, majnemer
Subscribers: aemerson, jyknight, llvm-commits
Differential Revision: https://reviews.llvm.org/D24047
llvm-svn: 281762
|
| |
|
|
| |
llvm-svn: 281760
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D24204
llvm-svn: 281758
|
| |
|
|
|
|
|
|
| |
Avoids losing GlobalsAA in the standard pass pipeline.
Differential Revision: https://reviews.llvm.org/D24094
llvm-svn: 281757
|
| |
|
|
| |
llvm-svn: 281752
|
| |
|
|
|
|
| |
was "used" but not used.
llvm-svn: 281749
|
| |
|
|
|
|
| |
accordingly.
llvm-svn: 281748
|
| |
|
|
| |
llvm-svn: 281745
|
| |
|
|
|
|
|
|
|
|
|
| |
as well
A follow-up patch will rename this pass and the source file accordingly,
but I figured the non-NFC change will be easier to spot in isolation.
Differential Revision: https://reviews.llvm.org/D24641
llvm-svn: 281744
|
| |
|
|
| |
llvm-svn: 281743
|
| |
|
|
| |
llvm-svn: 281742
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D24617
llvm-svn: 281741
|