| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
the SIB index register as an XMM/YMM/ZMM register.
This introduces a new operand type to encode the whether the index register should be XMM/YMM/ZMM. And new code to fixup the results created by readSIB.
This has the nice effect of removing a bunch of code that hard coded the name of every GATHER and SCATTER instruction to map the index type.
This fixes PR32807.
llvm-svn: 316273
|
| |
|
|
| |
llvm-svn: 316271
|
| |
|
|
|
|
|
|
|
|
| |
Summary: The two 32-bit words were swapped.
Subscribers: nemanjai, kbarton
Differential Revision: https://reviews.llvm.org/D38705
llvm-svn: 316270
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: __multi3 is not available on x86 (32-bit). Setting lib call name for MULI_128 to nullptr forces DAGTypeLegalizer::ExpandIntRes_MUL to generate instructions for 128-bit multiply instead of a call to an undefined function. This fixes PR20871 though it may be worth looking at why licm and indvars combine to generate 65-bit multiplies in that test.
Patch by Riyaz V Puthiyapurayil
Reviewers: craig.topper, schweitz
Reviewed By: craig.topper, schweitz
Subscribers: RKSimon, llvm-commits
Differential Revision: https://reviews.llvm.org/D38668
llvm-svn: 316254
|
| |
|
|
| |
llvm-svn: 316243
|
| |
|
|
|
|
|
|
|
| |
At this point we don't output any debug sections or thier
relocations.
Differential Revision: https://reviews.llvm.org/D39076
llvm-svn: 316240
|
| |
|
|
|
|
|
| |
ComplexRendererFn -> ComplexRendererFns
Corrected a couple lingering references to tied operands that were missed.
llvm-svn: 316237
|
| |
|
|
| |
llvm-svn: 316236
|
| |
|
|
| |
llvm-svn: 316228
|
| |
|
|
|
|
| |
To help identify shuffle combine issues
llvm-svn: 316222
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change comes from using lld for i686-windows-msvc. Before this change, lld
emits an error of:
error: relocation against symbol in discarded section: .xdata
It's possible that this could be addressed in lld, but I think this change is
reasonable on its own.
At a high level, this is being generated:
A (.text comdat) -> B (.text) -> C (.xdata comdat)
Where A is a C++ inline function, which references B, an exception handler
thunk, which references C, the exception handling info.
With this structure, lld will error when applying relocations to B if the C it
references has been discarded (some other C has been selected).
This change checks if A is comdat, and if so places the exception registration
thunk (B) in the comdata group of A (and B).
It appears that MSVC makes the __ehhandler function comdat.
Is it possible that duplicate thunks are being emitted into the final binary
with other linkers, or are they stripping the unused thunks?
Reviewers: rnk, majnemer, compnerd, smeenai
Reviewed By: rnk, compnerd
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38940
llvm-svn: 316219
|
| |
|
|
|
|
|
|
|
|
|
| |
Normally, if the registers holding the induction variable's bounds
are redefined inside of the loop's body, the loop cannot be converted
to a hardware loop. However, if the redefining instruction is actually
loading an immediate value into the register, this conversion is both
possible and legal (since the immediate itself will be used in the
loop setup in the preheader).
llvm-svn: 316218
|
| |
|
|
|
|
|
| |
This reverts commit r314507, because the original patch is causing test
failures.
llvm-svn: 316215
|
| |
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D39100
llvm-svn: 316214
|
| |
|
|
|
|
|
| |
The commit at https://reviews.llvm.org/rL315888 is causing some failures
with internal testing. Disabling this code until we can resolve the issues.
llvm-svn: 316199
|
| |
|
|
|
|
| |
r316188 didn't set guessInstructionProperties=1 as it should have done.
llvm-svn: 316189
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the minimum necessary to support codegen for simple ALU operations
on RV32. Prolog and epilog insertion, support for memory operations etc etc
follow in future patches.
Leave guessInstructionProperties=1 until https://reviews.llvm.org/D37065 is
reviewed and lands.
Differential Revision: https://reviews.llvm.org/D29933
llvm-svn: 316188
|
| |
|
|
|
|
| |
marked as legal.
llvm-svn: 316182
|
| |
|
|
|
|
|
|
|
|
| |
account by the getUserCost function. This was leading to some loops being over unrolled. The cost of a vector instruction is now being multiplied by the cost of the type legalization. This will return a more accurate cost.
Committing on behalf on Brad Nemanich (brad.nemanich@ibm.com)
Differential Revision: https://reviews.llvm.org/D38961
llvm-svn: 316174
|
| |
|
|
| |
llvm-svn: 316170
|
| |
|
|
|
|
|
| |
This is necessary to avoid an assertion in the included test case and similar
assembler inputs.
llvm-svn: 316168
|
| |
|
|
| |
llvm-svn: 316167
|
| |
|
|
|
|
|
|
|
|
|
|
| |
x86 has its own copy of integer absolute pattern matching to combine directly to a SUB+CMOV.
This patch removes the x86 combine and adds custom lowering support for ISD::ABS instead, allowing us to use the DAGCombiner version.
Additional test cases are already covered by iabs.ll (rL315706 and rL315711).
Differential Revision: https://reviews.llvm.org/D38895
llvm-svn: 316162
|
| |
|
|
|
|
|
|
|
|
| |
While parameterising by XLen, also take the opportunity to clean up the
formatting of the RISCV .td files.
This commit unifies the in-tree code with my patchset at
<https://github.com/lowrisc/riscv-llvm>.
llvm-svn: 316159
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch lets the llvm tools handle the new HVX target features that
are added by frontend (clang). The target-features are of the form
"hvx-length64b" for 64 Byte HVX mode, "hvx-length128b" for 128 Byte mode HVX.
"hvx-double" is an alias to "hvx-length128b" and is soon will be deprecated.
The hvx version target feature is upgated form "+hvx" to "+hvxv{version_number}.
Eg: "+hvxv62"
For the correct HVX code generation, the user must use the following
target features.
For 64B mode: "+hvxv62" "+hvx-length64b"
For 128B mode: "+hvxv62" "+hvx-length128b"
Clang picks a default length if none is specified. If for some reason,
no hvx-length is specified to llvm, the compilation will bail out.
There is a corresponding clang patch.
Differential Revision: https://reviews.llvm.org/D38851
llvm-svn: 316101
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D38850
llvm-svn: 316099
|
| |
|
|
|
|
|
|
| |
All loads of form V6_vL32b_{,cur,nt,tmp,nt_cur,nt_tmp}_{ai,pi,ppu} are
predicable on v62 (but not on v60). Mark them all as predicable in the
instruction definitions, and handle the v60 case in HII::isPredicable.
llvm-svn: 316098
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D38957
llvm-svn: 316097
|
| |
|
|
|
|
|
| |
r315275 set the IsLittleEndian parameter incorrectly. This patch corrects
this, and adds a test to ensure such mistakes will be caught in the future.
llvm-svn: 316091
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D38347
llvm-svn: 316085
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the case where there was a conditional branch followed by a unconditional
branch with debug instruction separating them, MipsInstrInfo::analyzeBranch
would not skip past debug instruction when searching for the second branch
which give erroneous results about the control flow of the block.
This could lead to the branch folder to merge the non-fall through case
into it's predecessor, leaving the conditional branch with a dangling
basic block operand.
This resolves PR34975.
Thanks to Alexander Richardson for reporting the issue!
Reviewers: atanasyan
Differential Revision: https://reviews.llvm.org/D39003
llvm-svn: 316084
|
| |
|
|
| |
llvm-svn: 316079
|
| |
|
|
|
|
|
| |
r315410 broke a number of things in the AVR backend, which are now
fixed.
llvm-svn: 316076
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
{v8i8,v16i8,v32i8,v64i8}
This patch adds accurate instructions cost.
The formula presents two cases(stride 3 and stride 4) and calculates the cost according to the VF and stride.
Reviewers:
1. delena
2. Farhana
3. zvi
4. dorit
5. Ayal
Differential Revision: https://reviews.llvm.org/D38762
Change-Id: If4cfbd4ac0e63694e8144cb78c7fa34850647ff7
llvm-svn: 316072
|
| |
|
|
|
|
|
|
|
|
|
| |
Helper functions to identify sign- and zero-extending machine instruction is introduced in rL315888.
This patch makes PPCInstrInfo::optimizeCompareInstr use the helper functions. It simplifies the code and also makes possible more optimizations since the helper can do more analysis than the original check code; I observed about 5000 more compare instructions are eliminated while building LLVM.
Also, this patch fixes a bug in helpers on ANDIo instruction handling due to the order of checks. This bug causes a failure in an existing test case for optimizeCompareInstr.
Differential Revision: https://reviews.llvm.org/D38988
llvm-svn: 316071
|
| |
|
|
|
| |
Change-Id: I7f13d5bcb181be2860377df7b40e1579a8ad4add
llvm-svn: 316067
|
| |
|
|
|
|
| |
Otherwise they are ambiguous in MIR.
llvm-svn: 316047
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D39014
llvm-svn: 316037
|
| |
|
|
|
|
|
|
|
|
|
| |
Note that cyclone itself doesn't fuse, but newer apple chips do and we
are using cyclone as the default when targeting apple OSes.
The current code also does not capture all fusion patterns of apple CPUs
yet; I am still looking for ways to refactor the code nicely to extend
it.
llvm-svn: 316036
|
| |
|
|
|
|
|
|
|
| |
If the address of a local is used in a comparison, AArch64 can fold the
address-calculation into the comparison via "adds". Unfortunately, a couple of
places (both hit in this one test) are not ready to deal with that yet and just
assume the first source operand is a register.
llvm-svn: 316035
|
| |
|
|
|
|
| |
warnings; other minor fixes (NFC).
llvm-svn: 316034
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D38958
llvm-svn: 316024
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Make sure the map is cleared before processing a new module. Similar to what is done on `StackMaps`.
This issue is similar to D38588, though this time for FaultMaps (on x86) rather than ARM/AArch64. Other than possible mixing of information between modules, the crash is caused by the pointers values in the map that was allocated by the bump pointer allocator that is unwinded when emitting the next file. This issue has been around since 3.8.
This issue is likely much harder to write a test for since AFAICT it requires emitting something much more compilcated (and possibly real code) instead of just some random bytes.
Reviewers: skatkov, sanjoy
Reviewed By: skatkov, sanjoy
Subscribers: sanjoy, aemerson, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D38924
llvm-svn: 315990
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Updated the scheduling information for the SkylakeClient target with the following changes:
1. regrouped the instructions after adding load and store latencies.
2. regrouped the instructions after adding identified missing ports in several groups.
The changes were made after revisiting the latencies impact of all the load and store uOps.
Reviewers: zvi, RKSimon, craig.topper
Differential Revision: https://reviews.llvm.org/D38727
Change-Id: I778a308cc11e490e8fa5e27e2047412a1dca029f
llvm-svn: 315978
|
| |
|
|
| |
llvm-svn: 315969
|
| |
|
|
|
|
|
|
| |
UpdateNodeOperands() modifies the node in-place and using the return value isn’t strictly necessary. However, it does not necessarily modify the node, but may return a resultant node if it already exists in the DAG. See comments in UpdateNodeOperands(). In that case, the return value must be used to avoid such scenarios as an infinite loop (node is assumed to have been updated, so added back to the worklist, and re-processed; however, node hasn’t changed so it is once again passed to UpdateNodeOperands(), assumed modified, added back to worklist; cycle infinitely repeats).
Differential Revision: https://reviews.llvm.org/D38466
llvm-svn: 315957
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for COPY
This reverts commit r315823, thus re-applying r315781.
Also make sure we don't use G_BITCAST mapping for non-generic registers.
Non-generic registers don't have a type but do have a reg bank.
Something the COPY mapping now how to deal with but the G_BITCAST
mapping don't.
-- Original Commit Message --
We use to resort on the generic implementation to get the mappings for
COPYs. The generic implementation resorts on table lookup and
dynamically allocated objects to get the valid mappings.
Given we already know how to map G_BITCAST and have the static mappings
for them, use that code path for COPY as well. This is much more
efficient.
Improve the compile time of RegBankSelect by up to 20%.
Note: When we eventually generate all the mappings via TableGen, we
wouldn't have to do that dance to shave compile time. The intent of this
change was to make sure that moving to static structure really pays off.
NFC.
llvm-svn: 315947
|
| |
|
|
|
|
| |
Anything bigger than 64-bit just map to FPR.
llvm-svn: 315946
|
| |
|
|
|
|
|
| |
We used to mark all G_BITCAST of 128-bit legal but only for vector
types. Scalars of this size are just fine as well.
llvm-svn: 315945
|
| |
|
|
| |
llvm-svn: 315927
|