| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 211110
|
|
|
|
| |
llvm-svn: 211109
|
|
|
|
| |
llvm-svn: 211108
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to store a value greater than or equal to the number of LDS
bytes allocated by the shader in the m0 register in order for LDS
instructions to work correctly.
We always initialize m0 at the beginning of a shader, but this register
is also used for indirect addressing offsets, so we need to
re-initialize it any time we use indirect addressing.
llvm-svn: 211107
|
|
|
|
|
|
|
| |
Overlooked that fcmp_une uses an "or" instead of an "and" for combining the
flags.
llvm-svn: 211104
|
|
|
|
| |
llvm-svn: 211097
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To make sure branches are in range, we need to do a better job of estimating
the length of an inline assembly block than "it's probably 1 instruction, who'd
write asm with more than that?".
Fortunately there's already a (highly suspect, see how many ways you can think
of to break it!) callback for this purpose, which is used by the other targets.
rdar://problem/17277590
llvm-svn: 211095
|
|
|
|
|
|
|
|
|
| |
function. NFC.
Make use of helper functions to simplify the branch and compare instruction
selection in FastISel. Also add test cases for compare and conditonal branch.
llvm-svn: 211077
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patches allows non conversions like i1=i2; where both are global ints.
In addition, arithmetic and other things start to work since fast-isel will use
existing patterns for non fast-isel from tablegen files where applicable.
In addition i8, i16 will work in this limited context for assignment without the need
for sign extension (zero or signed). It does not matter how i8 or i16 are loaded (zero or sign extended)
since only the 8 or 16 relevant bits are used and clang will ask for sign extension before using them in
arithmetic. This is all made more complete in forthcoming patches.
for example:
int i, j=1, k=3;
void foo() {
i = j + k;
}
Keep in mind that this pass is not enabled right now and is an experimental pass
It can only be enabled with a hidden option to llvm of -mips-fast-isel.
Test Plan: Run test-suite, loadstore2.ll and I will run some executable tests.
Reviewers: dsanders
Subscribers: mcrosier
Differential Revision: http://reviews.llvm.org/D3856
llvm-svn: 211061
|
|
|
|
|
|
|
|
|
| |
Define an intrinsic for the frontend to use and pattern match it to
the RBIT instruction.
rdar://9283021
llvm-svn: 211058
|
|
|
|
|
|
|
|
|
| |
We already have an ARMISD node. Create an intrinsic to map to it so we can
add support for the frontend __rbit() intrinsic.
rdar://9283021
llvm-svn: 211057
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rafael opened http://llvm.org/bugs/show_bug.cgi?id=19893 to track non-optimal
code generation for forming a function address that is local to the compile
unit. The existing code was treating both local and non-local functions
identically.
This patch fixes the problem by properly identifying local functions and
generating the proper addis/addi code. I also noticed that Rafael's earlier
changes to correct the surrounding code in PPCISelLowering.cpp were also
needed for fast instruction selection in PPCFastISel.cpp, so this patch
fixes that code as well.
The existing test/CodeGen/PowerPC/func-addr.ll is modified to test the new
code generation. I've added a -O0 run line to test the fast-isel code as
well.
Tested on powerpc64[le]-unknown-linux-gnu with no regressions.
llvm-svn: 211056
|
|
|
|
|
|
| |
and query the base target machine implementation for it.
llvm-svn: 211055
|
|
|
|
|
|
|
|
| |
Added comment to clarify why we r211040 choose to bail out of fast isel instead
of generating a more complicated relocation, and fix mislabelled register in the
comments of the asan test case.
llvm-svn: 211052
|
|
|
|
|
|
|
|
|
|
| |
ARM v7M has ldrex/strex but not ldrexd/strexd. This means 32-bit
operations should work as normal, but 64-bit ones are almost certainly
doomed.
Patch by Phoebe Buckheister.
llvm-svn: 211042
|
|
|
|
|
|
|
|
|
|
|
|
| |
On x86_86 the lea instruction can only use a 32 bit immediate value. When
the code is compiled statically the RIP register is not used, meaning the
immediate is all that can be used for the relocation, which is not sufficient
in the case of targets more than +/- 2GB away. This patch bails out of fast
isel in those cases and reverts to DAG which does the right thing.
Test case included.
llvm-svn: 211040
|
|
|
|
|
|
|
|
| |
Originally I switched the LD/ST optimizer off in TargetMachine as it was previously, but Eric has suggested he'd prefer that it be short-circuited in the pass itself.
No functionality change.
llvm-svn: 211037
|
|
|
|
|
|
| |
Both function declarations lack a callee and an implementation.
llvm-svn: 211029
|
|
|
|
| |
llvm-svn: 211024
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Depends on D4120
Reviewers: jkolek, zoran.jovanovic, vmedic
Reviewed By: zoran.jovanovic, vmedic
Differential Revision: http://reviews.llvm.org/D4121
llvm-svn: 211021
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There is no change to the restrictions, just the result register is stored
once in the encoding rather than twice. The rt field is zero in
MIPS32r6/MIPS64r6.
Depends on D4119
Reviewers: zoran.jovanovic, jkolek, vmedic
Reviewed By: vmedic
Differential Revision: http://reviews.llvm.org/D4120
llvm-svn: 211019
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The linked-load, store-conditional operations have been re-encoded such
that have a 9-bit offset instead of the 16-bit offset they have prior to
MIPS32r6/MIPS64r6.
While implementing this, I noticed that the atomic load/store pseudos always
emit a sign extension using sll and sra. I have improved this to use seb/seh
when they are available (MIPS32r2/MIPS64r2 and above).
Depends on D4118
Reviewers: jkolek, zoran.jovanovic, vmedic
Reviewed By: vmedic
Differential Revision: http://reviews.llvm.org/D4119
llvm-svn: 211018
|
|
|
|
|
|
| |
Patch by Jiangning Liu!
llvm-svn: 211014
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rather than 16-bit in MIPS32r6/MIPS64r6
Summary:
The error message for the invalid.s cases isn't very helpful. It happens because
there is an instruction with a wider immediate that would have matched if the
NotMips32r6 predicate were true. I have some WIP to improve the message but it
affects most error messages for removed/re-encoded instructions on
MIPS32r6/MIPS64r6 and should therefore be a separate commit.
Depens on D4115
Reviewers: zoran.jovanovic, jkolek, vmedic
Reviewed By: vmedic
Differential Revision: http://reviews.llvm.org/D4117
llvm-svn: 211012
|
|
|
|
|
|
| |
Reviewed at http://reviews.llvm.org/D4135
llvm-svn: 211010
|
|
|
|
| |
llvm-svn: 211003
|
|
|
|
|
|
|
| |
Try to keep all the setOperationActions for integer ops
together.
llvm-svn: 211001
|
|
|
|
| |
llvm-svn: 211000
|
|
|
|
| |
llvm-svn: 210998
|
|
|
|
| |
llvm-svn: 210997
|
|
|
|
|
|
| |
back.
llvm-svn: 210996
|
|
|
|
|
|
| |
Divides by weird constants now emit much better code.
llvm-svn: 210995
|
|
|
|
| |
llvm-svn: 210994
|
|
|
|
|
|
|
|
| |
There's probably no acatual change in behaviour here, just updating
the LowerFP_TO_INT function to be more similar to the reverse
implementation and updating costs to current CodeGen.
llvm-svn: 210985
|
|
|
|
|
|
|
| |
This somehow got missed in the AArch64 merge, so should fix a
performance regression since 3.4.
llvm-svn: 210984
|
|
|
|
| |
llvm-svn: 210968
|
|
|
|
|
|
|
|
|
|
|
| |
This would assert if a constant address space was extern
and therefore didn't have an initializer. If the initializer
was undef, it would hit the unreachable unhandled initializer case.
An extern global should never really occur since we don't have
machine linking, but bugpoint likes to remove initializers.
llvm-svn: 210967
|
|
|
|
| |
llvm-svn: 210966
|
|
|
|
|
|
| |
on the subtarget and just forward the accessor.
llvm-svn: 210955
|
|
|
|
|
|
| |
This required untangling a mess of headers that included around.
llvm-svn: 210953
|
|
|
|
|
|
| |
so make it take one. Fix up all users accordingly.
llvm-svn: 210948
|
|
|
|
| |
llvm-svn: 210947
|
|
|
|
|
|
|
|
|
|
|
| |
Lowering this new node allows us to fold the almost universal
comparison for success before it's even formed. Instead we can create
a copy from EFLAGS and an X86ISD::SETCC operation since all "cmpxchg"
instructions set the zero-flag to the correct value.
rdar://problem/13201607
llvm-svn: 210923
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move / delete some of the more obviously wrong
setOperationAction calls. Most of these are setting Expand
for types that aren't legal which is the default anyway.
Leave stuff that might require more thought on whether it's
junk or not as it is.
No functionality change.
llvm-svn: 210922
|
|
|
|
|
|
| |
Most of these are no longer used any more.
llvm-svn: 210915
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3890
llvm-svn: 210908
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds a weak variant of the cmpxchg operation, as described
in C++11. A cmpxchg instruction with this modifier is permitted to
fail to store, even if the comparison indicated it should.
As a result, cmpxchg instructions must return a flag indicating
success in addition to their original iN value loaded. Thus, for
uniformity *all* cmpxchg instructions now return "{ iN, i1 }". The
second flag is 1 when the store succeeded.
At the DAG level, a new ATOMIC_CMP_SWAP_WITH_SUCCESS node has been
added as the natural representation for the new cmpxchg instructions.
It is a strong cmpxchg.
By default this gets Expanded to the existing ATOMIC_CMP_SWAP during
Legalization, so existing backends should see no change in behaviour.
If they wish to deal with the enhanced node instead, they can call
setOperationAction on it. Beware: as a node with 2 results, it cannot
be selected from TableGen.
Currently, no use is made of the extra information provided in this
patch. Test updates are almost entirely adapting the input IR to the
new scheme.
Summary for out of tree users:
------------------------------
+ Legacy Bitcode files are upgraded during read.
+ Legacy assembly IR files will be invalid.
+ Front-ends must adapt to different type for "cmpxchg".
+ Backends should be unaffected by default.
llvm-svn: 210903
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
cache and pref were added in MIPS-III, and MIPS32 but were re-encoded in
MIPS32r6/MIPS64r6 to use a 9-bit offset rather than the 16-bit offset
available to earlier cores.
Resolved the decoding conflict between pref and lwc3.
Depends on D4115
Reviewers: zoran.jovanovic, jkolek, vmedic
Reviewed By: vmedic
Differential Revision: http://reviews.llvm.org/D4116
llvm-svn: 210900
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
These MIPS-3D instructions have never been implemented in LLVM so we only
add testcases.
Reviewers: zoran.jovanovic, jkolek, vmedic
Reviewed By: vmedic
Differential Revision: http://reviews.llvm.org/D4115
llvm-svn: 210899
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is a normal instruction
Summary:
b(ge|lt)zal have been removed in MIPS32r6/MIPS64r6. However, bal (an alias
for 'bgezal $zero, $offset') still remains with the same encoding it had
prior to MIPS32r6/MIPS64r6.
Updated the MipsNaCLELFStreamer, and MipsLongBranch to correctly handle the
MIPS32r6/MIPS64r6 BAL instruction in addition to the existing BAL_BR pseudo.
No changes were required to the CodeGen test that looks for BAL
(test/CodeGen/Mips/longbranch.ll) since the new instruction has the same
syntax.
Depends on D4113
Reviewers: jkolek, zoran.jovanovic, vmedic
Reviewed By: vmedic
Differential Revision: http://reviews.llvm.org/D4114
llvm-svn: 210898
|