| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
This reverts commit r218254.
The global_atomics.ll test fails with asserts disabled. For some reason,
the compiler fails to produce the atomic no return variants.
llvm-svn: 218257
|
|
|
|
| |
llvm-svn: 218254
|
|
|
|
| |
llvm-svn: 218165
|
|
|
|
| |
llvm-svn: 218164
|
|
|
|
| |
llvm-svn: 218162
|
|
|
|
| |
llvm-svn: 218131
|
|
|
|
|
|
| |
Just do the left shift as unsigned to avoid the UB.
llvm-svn: 218092
|
|
|
|
|
|
|
| |
I'm not sure what the hardware actually does, so don't
bother trying to fold it for now.
llvm-svn: 218057
|
|
|
|
| |
llvm-svn: 217979
|
|
|
|
|
|
|
|
|
|
| |
Only 1 decimal place should be printed for inline immediates.
Other constants should be hex constants.
Does not include f64 tests because folding those inline
immediates currently does not work.
llvm-svn: 217964
|
|
|
|
|
|
|
|
| |
Add some more tests to make sure better operand
choices are still made. Leave some cases that seem
to have no reason to ever be e64 alone.
llvm-svn: 217789
|
|
|
|
| |
llvm-svn: 217787
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I noticed some odd looking cases where addr64 wasn't set
when storing to a pointer in an SGPR. This seems to be intentional,
and partially tested already.
The documentation seems to describe addr64 in terms of which registers
addressing modifiers come from, but I would expect to always need
addr64 when using 64-bit pointers. If no offset is applied,
it makes sense to not need to worry about doing a 64-bit add
for the final address. A small immediate offset can be applied,
so is it OK to not have addr64 set if a carry is necessary when adding
the base pointer in the resource to the offset?
llvm-svn: 217785
|
|
|
|
| |
llvm-svn: 217777
|
|
|
|
| |
llvm-svn: 217736
|
|
|
|
|
|
|
| |
The register numbers start at 0, so if only 1 register
was used, this was reported as 0.
llvm-svn: 217636
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do
(shl (add x, c1), c2) -> (add (shl x, c2), c1 << c2)
This is already done for multiplies, but since multiplies
by powers of two are turned into shifts, we also need
to handle it here.
This might want checks for isLegalAddImmediate to avoid
transforming an add of a legal immediate with one that isn't.
llvm-svn: 217610
|
|
|
|
|
|
|
|
| |
Now that the operations are all implemented, we can test this sub-arch here.
Signed-off-by: Aaron Watry <awatry@gmail.com>
Reviewed-by: Matt Arsenault <matthew.arsenault@amd.com>
llvm-svn: 217595
|
|
|
|
|
|
|
| |
The lost chain resulting in earlier side effecting nodes
being deleted.
llvm-svn: 217561
|
|
|
|
| |
llvm-svn: 217553
|
|
|
|
| |
llvm-svn: 217379
|
|
|
|
| |
llvm-svn: 217320
|
|
|
|
|
|
| |
Fix missing check, and hardcoded register numbers.
llvm-svn: 217318
|
|
|
|
|
|
|
| |
This fixes hitting the same negative base offset problem
that was already fixed for regular loads and stores.
llvm-svn: 217256
|
|
|
|
|
|
|
|
| |
round halfway cases away from zero
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Tom Stellard <tom@stellard.net>
llvm-svn: 217250
|
|
|
|
|
|
| |
https://bugs.freedesktop.org/show_bug.cgi?id=83416
llvm-svn: 217248
|
|
|
|
|
|
|
| |
Also fix bug this exposed where when legalizing an immediate
operand, a v_mov_b32 would be created with a VSrc dest register.
llvm-svn: 217108
|
|
|
|
| |
llvm-svn: 217041
|
|
|
|
|
|
| |
This will help with enabling misched
llvm-svn: 216971
|
|
|
|
| |
llvm-svn: 216944
|
|
|
|
|
|
|
| |
This is broken when 64-bit add is only partially
moved to the VALU.
llvm-svn: 216933
|
|
|
|
|
|
|
|
| |
If an fmul was introduced by lowering, it wouldn't be folded
into a multiply by a constant since the earlier combine would
have replaced the fmul with the fadd.
llvm-svn: 216932
|
|
|
|
|
|
|
| |
We can use a negate source modifier to match
this for fsub.
llvm-svn: 216735
|
|
|
|
| |
llvm-svn: 216279
|
|
|
|
| |
llvm-svn: 216278
|
|
|
|
| |
llvm-svn: 216220
|
|
|
|
|
|
| |
This fixes a crash in an ocl conformance test.
llvm-svn: 216219
|
|
|
|
| |
llvm-svn: 215749
|
|
|
|
| |
llvm-svn: 215748
|
|
|
|
| |
llvm-svn: 215747
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ordinarily (shl (add x, c1), c2) -> (add (shl x, c2), c1 << c2)
is only done if the add has one use. If the resulting constant
add can be folded into an addressing mode, force this to happen
for the pointer operand.
This ends up happening a lot because of how LDS objects are allocated.
Since the globals are allocated next to each other, acessing the first
element of the second object is directly indexed by a shifted pointer.
llvm-svn: 215739
|
|
|
|
| |
llvm-svn: 215734
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The default assumes that a 16-bit signed offset is used.
LDS instruction use a 16-bit unsigned offset, so it wasn't
being used in some cases where it was assumed a negative offset
could be used.
More should be done here, but first isLegalAddressingMode needs
to gain an addressing mode argument. For now, copy most of the rest
of the default implementation with the immediate offset change.
llvm-svn: 215732
|
|
|
|
|
|
|
|
|
|
| |
This for some reason fixes v1i64 kernel arguments on pre-SI. This
currently breaks some other cases in the kernel-args.ll test for R600,
but I'm not particularly confident in the new output. VTX_READ_* are not
used for some of the scalarized cases, and the code reading from the
constant buffer doesn't make much sense to me.
llvm-svn: 215564
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately, our use of the SDNode class hierarchy for INTRINSIC_W_CHAIN and
INTRINSIC_VOID nodes is somewhat broken right now. These nodes sometimes are
used for memory intrinsics (those with MachineMemOperands), and sometimes not.
When not, the nodes are not created as instances of MemIntrinsicSDNode, but
rather created as some other subclass of SDNode using DAG::getNode. When they
are memory intrinsics, they are created using DAG::getMemIntrinsicNode as
instances of MemIntrinsicSDNode. MemIntrinsicSDNode is a subclass of
MemSDNode, but prior to r214452, we had a non-self-consistent setup whereby
MemIntrinsicSDNode::classof on INTRINSIC_W_CHAIN and INTRINSIC_VOID would
return true but MemSDNode::classof on INTRINSIC_W_CHAIN and INTRINSIC_VOID
would return false. In r214452, MemSDNode::classof was changed to return true
for INTRINSIC_W_CHAIN and INTRINSIC_VOID, which is now self-consistent. The
problem is that neither the pre-r214452 logic and the post-r214452 logic are
really right. The truth is that not all INTRINSIC_W_CHAIN and INTRINSIC_VOID
nodes are instances of MemIntrinsicSDNode (or MemSDNode for that matter), and
the return value from classof needs to reflect that. This was broken before
r214452 (because MemIntrinsicSDNode::classof always returned true), and was
broken afterward (because MemSDNode::classof also always returned true), and
will now be correct.
The minimal solution is to grab one of the SubclassData bits (there is one left
for MemIntrinsicSDNode nodes) and use it to store whether or not a particular
INTRINSIC_W_CHAIN or INTRINSIC_VOID is really an instance of
MemIntrinsicSDNode or not. Doing this allows both MemIntrinsicSDNode::classof
and MemSDNode::classof to return the correct answer for the underlying object
for both the memory-intrinsic and non-memory-intrinsic cases.
This fixes the problem that r214452 created in the SelectionDAGDumper (thanks
to Matt Arsenault for pointing it out).
Because PowerPC does not implement getTgtMemIntrinsic, this change breaks
test/CodeGen/PowerPC/unal-altivec-wint.ll. I've XFAILed it for now, and will
fix it in a follow-up commit.
llvm-svn: 215511
|
|
|
|
|
|
|
|
|
| |
v2: drop enum keyword
use correct extension mode
don't bother computing the sign in unsinged case
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 215462
|
|
|
|
|
|
|
|
|
| |
v2: add tests
rename LowerSDIV24 to LowerSDIVREM24
handle the rem part in this function
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 215460
|
|
|
|
|
|
|
| |
This saves us from having to copy a 64-bit 0 value into VGPRs for
BUFFER_* instruction which only have a 12-bit immediate offset.
llvm-svn: 215399
|
|
|
|
|
|
|
|
| |
There are no variable values like registers encoded in the low 32 bits of MUBUF
instructions, so it is relatively easy to check these bits, and it will
help prevent us from introducing encoding bugs.
llvm-svn: 215397
|
|
|
|
|
|
|
|
| |
This bit was left uninitialized, which was causing some random failures
of piglit tests.
NOTE: This is a candidate for the 3.5 branch.
llvm-svn: 215396
|