| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 186613
|
|
|
|
|
|
| |
https://bugs.freedesktop.org/show_bug.cgi?id=65873
llvm-svn: 186339
|
|
|
|
|
|
| |
r186196.
llvm-svn: 186209
|
|
|
|
|
|
|
| |
I'm guessing the failure had something to do with the double precision
floating point constant used in the test.
llvm-svn: 186191
|
|
|
|
|
|
|
| |
Patch by: Niels Ole Salscheider
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186182
|
|
|
|
|
|
|
| |
Patch by: Niels Ole Salscheider
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186181
|
|
|
|
|
|
|
| |
Patch by: Niels Ole Salscheider
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186180
|
|
|
|
|
|
|
| |
Patch by: Niels Ole Salscheider
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186179
|
|
|
|
|
|
|
| |
Patch by: Niels Ole Salscheider
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186178
|
|
|
|
|
|
|
| |
Patch by: Niels Ole Salscheider
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186177
|
|
|
|
|
|
|
| |
Enough for the radeonsi driver to use it for calculating derivatives.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186012
|
|
|
|
|
| |
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186010
|
|
|
|
|
| |
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 186008
|
|
|
|
|
|
|
|
|
| |
Test is not included as it is several 1000 lines long.
To test this functionnality, a test case must generate at least 2 ALU clauses,
where an ALU clause is ~110 instructions long.
NOTE: This is a candidate for the stable branch.
llvm-svn: 185943
|
|
|
|
| |
llvm-svn: 185942
|
|
|
|
| |
llvm-svn: 185941
|
|
|
|
|
| |
NOTE: This is a candidate for the stable branch.
llvm-svn: 185940
|
|
|
|
| |
llvm-svn: 185554
|
|
|
|
| |
llvm-svn: 185268
|
|
|
|
|
| |
Reviewed-by: Vincent Lejeune<vljn at ovi.com>
llvm-svn: 185162
|
|
|
|
|
| |
Reviewed-by: Vincent Lejeune<vljn at ovi.com>
llvm-svn: 185161
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The purpose of this test was to check boundary conditions for the size
of an ALU clause. This test is very sensitive to changes to the
optimizer or scheduler, because it requires an exact number of ALU
instructions in order to remain valid. It's not good to have a test
this sensitive, because it is confusing to developers who implement
optimizations and then 'break' the test.
I'm not sure if there is a good way to test these limits using lit, but
if I can come up with replacement test that isn't as sensitive I'll add
it back to the tree.
llvm-svn: 185084
|
|
|
|
| |
llvm-svn: 184880
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note: Only adding test for evergreen, not SI yet.
When I attempted to expand vselect for SI, I got the following:
llc: /home/awatry/src/llvm/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp:522:
llvm::SDValue llvm::DAGTypeLegalizer::PromoteIntRes_SETCC(llvm::SDNode*):
Assertion `SVT.isVector() == N->getOperand(0).getValueType().isVector() &&
"Vector compare must return a vector result!"' failed.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 184847
|
|
|
|
|
|
|
| |
Add test cases for both vector sizes on SI and also add v2i32 test for EG.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 184846
|
|
|
|
|
|
|
|
|
|
| |
No test/expansion for SI has been added yet. Attempts to expand this
operation for SI resulted in a stacktrace in (IIRC) LegalizeIntegerTypes
which was complaining about vector comparisons being required to return
a vector type.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 184845
|
|
|
|
|
|
|
|
|
|
|
| |
Also add lit test for both cases on SI, and v2i32 for evergreen.
Note: I followed the guidance of the v4i32 EG check... UREM produces really
complex code, so let's just check that the instruction was lowered
successfully.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 184844
|
|
|
|
|
|
|
|
|
|
|
| |
Also add lit test for both cases on SI, and v2i32 for evergreen.
Note: I followed the guidance of the v4i32 EG check... UDIV produces really
complex code, so let's just check that the instruction was lowered
successfully.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 184843
|
|
|
|
|
|
|
| |
Also add lit test for both cases on SI, and v2i32 for evergreen.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 184842
|
|
|
|
|
|
|
| |
Also add lit test for both cases on SI, and v2i32 for evergreen.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 184841
|
|
|
|
|
|
|
| |
Also add lit test for both cases on SI, and v2i32 for evergreen.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 184840
|
|
|
|
|
|
|
| |
Also add lit test for both cases on SI, and v2i32 for evergreen.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 184839
|
|
|
|
|
|
|
| |
Also add lit test for both cases on SI, and v2i32 for evergreen.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 184838
|
|
|
|
|
|
|
| |
Also add lit test for both cases on SI, and v2i32 for evergreen.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 184837
|
|
|
|
|
|
|
|
|
|
|
| |
In reality, some unaligned memory accesses are legal for 32-bit types and
smaller too, but it all depends on the address space. Allowing
unaligned loads/stores for > 32-bit types is mainly to prevent the
legalizer from splitting one load into multiple loads of smaller types.
https://bugs.freedesktop.org/show_bug.cgi?id=65873
llvm-svn: 184822
|
|
|
|
|
| |
Tested-By: Aaron Watry <awatry@gmail.com>
llvm-svn: 184821
|
|
|
|
|
| |
Tested-By: Aaron Watry <awatry@gmail.com>
llvm-svn: 184820
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should only make a difference in programs that use a lot of the
vector ALU instructions like BFI_INT and BIT_ALIGN. There is a slight
improvement in the phatk bitcoin mining kernel with this patch on
Evergreen (vector size == 1):
Before:
1173 Instruction Groups / 9520 dwords
After:
1167 Instruction Groups / 9510 dwords
Reviewed-by: Reviewed-by: Vincent Lejeune<vljn at ovi.com>
llvm-svn: 184819
|
|
|
|
|
|
|
|
|
|
| |
Also add a v2i32 test to the existing v4i32 test.
Patch by: Aaron Watry
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Aaron Watry<awatry@gmail.com>
llvm-svn: 184482
|
|
|
|
|
|
|
|
|
|
|
| |
Also add SI tests to existing file and a v2i32 test for both
R600 and SI.
Patch by: Aaron Watry
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Aaron Watry <awatry@gmail.com>
llvm-svn: 184481
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The custom lowering causes llc to crash with a segfault.
Ideally, the custom lowering can be fixed, but this allows
programs which load/store v2i32 to work without crashing.
Patch by: Aaron Watry
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Aaron Watry<awatry@gmail.com>
llvm-svn: 184480
|
|
|
|
| |
llvm-svn: 184117
|
|
|
|
|
|
|
| |
Fixes rv7x0 bug in Heaven reported here:
https://bugs.freedesktop.org/show_bug.cgi?id=64257
llvm-svn: 184116
|
|
|
|
|
|
|
|
|
|
|
| |
Also add a seperate vector lit test file, since r600 doesn't seem to handle
v2i32 load/store yet, but we can test both for SI.
Patch by: Aaron Watry
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Aaron Watry <awatry@gmail.com>
llvm-svn: 184021
|
|
|
|
|
| |
Reviewed-by: Vincent Lejeune<vljn at ovi.com>
llvm-svn: 184016
|
|
|
|
|
|
|
|
|
| |
We were using RAT_INST_STORE_RAW, which seemed to work, but the docs
say this instruction doesn't exist for Cayman, so it's probably safer
to use a documented instruction instead.
Reviewed-by: Vincent Lejeune<vljn at ovi.com>
llvm-svn: 184015
|
|
|
|
| |
llvm-svn: 183592
|
|
|
|
|
|
|
|
|
| |
We weren't computing structure size correctly and we were relying on
the original alloca instruction to compute the offset, which isn't
always reliable.
Reviewed-by: Vincent Lejeune <vljn@ovi.com>
llvm-svn: 183568
|
|
|
|
|
|
|
|
| |
Reviewed-by: Vincent Lejeune <vljn@ovi.com>
https://bugs.freedesktop.org/show_bug.cgi?id=64257
llvm-svn: 183560
|
|
|
|
|
|
|
| |
Previously commited @183279 but tests were failing, reverted @183286
It was broken because @183336 was missing, now it's there.
llvm-svn: 183343
|