| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 208430
|
|
|
|
| |
llvm-svn: 208429
|
|
|
|
| |
llvm-svn: 208344
|
|
|
|
| |
llvm-svn: 208005
|
|
|
|
|
|
|
| |
Our OpenGL driver needs 22 SGPRs (16 user SGPRs + 6 streamout non-user SGPRs).
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
llvm-svn: 207990
|
|
|
|
|
|
|
| |
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Samuel Li <samuel.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
llvm-svn: 207846
|
|
|
|
|
|
|
|
| |
v2: move code to AMDGPUISelLowering.cpp
squash with tests (both EG and SI)
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 207845
|
|
|
|
| |
llvm-svn: 207844
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The register spiller assumes that only one new instruction is created
when spilling and restoring registers, so we need to emit pseudo
instructions for vector register spills and lower them after
register allocation.
v2:
- Fix calculation of lane index
- Extend VGPR liveness to end of program.
v3:
- Use SIMM16 field of S_NOP to specify multiple NOPs.
https://bugs.freedesktop.org/show_bug.cgi?id=75005
llvm-svn: 207843
|
|
|
|
|
|
|
|
| |
Use i32 instead of specifying SReg_32. When this is
the pseudo INDIRECT_BASE_ADDR, this would give a bogus
verifier error.
llvm-svn: 207770
|
|
|
|
|
|
|
|
|
| |
We can't use SALU instructions for this since they ignore the EXEC mask
and are always executed.
This fixes several OpenCV tests.
llvm-svn: 207661
|
|
|
|
| |
llvm-svn: 207660
|
|
|
|
| |
llvm-svn: 207654
|
|
|
|
|
|
| |
introduced most of these recently.
llvm-svn: 207616
|
|
|
|
|
|
| |
anything. In some cases remove all together if there are no callers either.
llvm-svn: 207610
|
|
|
|
|
|
|
|
|
|
| |
It's already set in AMDGPUISelLowering for all GPUs
Patch By: Jan Vesely
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 207592
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SI_IF and SI_ELSE are terminators which also produce a value. For
these instructions ISel always inserts a COPY to move their value
to another basic block. This COPY ends up between SI_(IF|ELSE)
and the S_BRANCH* instruction at the end of the block.
This breaks MachineBasicBlock::getFirstTerminator() and also the
machine verifier which assumes that terminators are grouped together at
the end of blocks.
To solve this we coalesce the copy away right after ISel to make sure
there are no instructions in between terminators at the end of blocks.
llvm-svn: 207591
|
|
|
|
|
|
|
|
| |
SALU instructions ignore control flow, so it is not always safe to use
them within branches. This is a partial solution to this problem
until we can come up with something better.
llvm-svn: 207590
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a squash of several optimization commits:
- calculate DIV_Lo and DIV_Hi separately
- use BFE_U32 if we are operating on 32bit values
- use precomputed constants instead of shifting in UDVIREM
- skip the first 32 iterations of udivrem
v2: Check whether BFE is supported before using it
Patch by: Jan Vesely
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 207589
|
|
|
|
|
|
|
|
|
|
| |
Initial implementation, rather slow
Patch by: Jan Vesely
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 207588
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When legalizing ops, with UDIV/UREM set to expand, they automatically
expand to UDIVREM (if legal or custom).
We need to do this manually for legalize types.
v2:
SI should be set to Expand because the type is legal, and it is
automatically lowered to UDIVREM if UDIVREM is Legal/Custom
R600 should set to UDIV/UREM to Custom because it needs to lower them
during type legalization
Patch by: Jan Vesely
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 207587
|
|
|
|
|
|
|
|
| |
Patch by: Jan Vesely
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 207586
|
|
|
|
|
|
| |
'final' and leave 'virtual' on some methods that are marked virtual without overriding anything and have no obvious overrides themselves. R600 edition
llvm-svn: 207503
|
|
|
|
| |
llvm-svn: 207397
|
|
|
|
| |
llvm-svn: 207394
|
|
|
|
| |
llvm-svn: 207378
|
|
|
|
| |
llvm-svn: 207377
|
|
|
|
| |
llvm-svn: 207374
|
|
|
|
|
|
| |
and size.
llvm-svn: 207329
|
|
|
|
| |
llvm-svn: 207327
|
|
|
|
|
|
|
|
| |
v2: Check both ExternalSymbol and GlobalAddress
Patch by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 207282
|
|
|
|
|
|
|
|
|
|
| |
It's fishy to be changing the `std::vector<>` owned by the iterator, and
no one actual does it, so I'm going to remove the ability in a
subsequent commit. First, update the users.
<rdar://problem/14292693>
llvm-svn: 207252
|
|
|
|
| |
llvm-svn: 207197
|
|
|
|
| |
llvm-svn: 207126
|
|
|
|
| |
llvm-svn: 206904
|
|
|
|
| |
llvm-svn: 206902
|
|
|
|
|
|
|
| |
Don't introduce new operations on an illegal sub 32-bit type.
Do the operations on a 32-bit value, and then use a truncating store.
llvm-svn: 206864
|
|
|
|
|
|
| |
Don't know why I didn't just do this in the first place.
llvm-svn: 206862
|
|
|
|
|
|
|
| |
definition below all of the header #include lines, lib/Target/...
edition.
llvm-svn: 206842
|
|
|
|
|
|
|
|
|
|
|
|
| |
system headers above the includes of generated '.inc' files that
actually contain code. In a few targets this was already done pretty
consistently, but it wasn't done *really* consistently anywhere. It is
strictly cleaner IMO and necessary in a bunch of places where the
DEBUG_TYPE is referenced from the generated code. Consistency with the
necessary places trumps. Hopefully the build bots are OK with the
movement of intrin.h...
llvm-svn: 206838
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
behavior based on other files defining DEBUG_TYPE, which means it cannot
define DEBUG_TYPE at all. This is actually better IMO as it forces folks
to define relevant DEBUG_TYPEs for their files. However, it requires all
files that currently use DEBUG(...) to define a DEBUG_TYPE if they don't
already. I've updated all such files in LLVM and will do the same for
other upstream projects.
This still leaves one important change in how LLVM uses the DEBUG_TYPE
macro going forward: we need to only define the macro *after* header
files have been #include-ed. Previously, this wasn't possible because
Debug.h required the macro to be pre-defined. This commit removes that.
By defining DEBUG_TYPE after the includes two things are fixed:
- Header files that need to provide a DEBUG_TYPE for some inline code
can do so by defining the macro before their inline code and undef-ing
it afterward so the macro does not escape.
- We no longer have rampant ODR violations due to including headers with
different DEBUG_TYPE definitions. This may be mostly an academic
violation today, but with modules these types of violations are easy
to check for and potentially very relevant.
Where necessary to suppor headers with DEBUG_TYPE, I have moved the
definitions below the includes in this commit. I plan to move the rest
of the DEBUG_TYPE macros in LLVM in subsequent commits; this one is big
enough.
The comments in Debug.h, which were hilariously out of date already,
have been updated to reflect the recommended practice going forward.
llvm-svn: 206822
|
|
|
|
| |
llvm-svn: 206784
|
|
|
|
|
|
|
|
| |
break the API.
No functionality change.
llvm-svn: 206740
|
|
|
|
|
|
| |
Fix indentation, better line wrapping, unused includes.
llvm-svn: 206562
|
|
|
|
|
|
|
|
| |
Use scalar BFE with constant shift and offset when possible.
This is complicated by the fact that the scalar version packs
the two operands of the vector version into one.
llvm-svn: 206558
|
|
|
|
| |
llvm-svn: 206547
|
|
|
|
| |
llvm-svn: 206541
|
|
|
|
| |
llvm-svn: 206501
|
|
|
|
|
|
|
|
|
| |
Having i128 as a legal type complicates the legalization phase. v4i32
is already a legal type, so we will use that instead.
This fixes several piglit tests.
llvm-svn: 206500
|
|
|
|
|
|
| |
SIFixSGPRCopies is smart enough to handle this now.
llvm-svn: 206499
|