History log of /llvm-project/llvm/lib/Target/NVPTX/NVPTXRegisterInfo.cpp (Results 26 – 38 of 38)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 84e68b29 22-Apr-2014 Chandler Carruth <chandlerc@gmail.com>

[Modules] Fix potential ODR violations by sinking the DEBUG_TYPE
definition below all of the header #include lines, lib/Target/...
edition.

llvm-svn: 206842


Revision tags: llvmorg-3.4.1-rc1
# 840beec2 04-Apr-2014 Craig Topper <craig.topper@gmail.com>

Make consistent use of MCPhysReg instead of uint16_t throughout the tree.

llvm-svn: 205610


Revision tags: llvmorg-3.4.0, llvmorg-3.4.0-rc3, llvmorg-3.4.0-rc2, llvmorg-3.4.0-rc1, llvmorg-3.3.1-rc1
# f8f70917 28-Jun-2013 Justin Holewinski <jholewinski@nvidia.com>

[NVPTX] Remove i8 register class. PTX support for i8 (.b8, .u8, .s8) is rather poor and we're better off just ignoring it and letting LLVM expand all i8 ops out to i16.

llvm-svn: 185174


# 3a601dd0 19-Jun-2013 Bill Wendling <isanbard@gmail.com>

Don't pass in the TargetInstrInfo into the register info object. It doesn't use it.

llvm-svn: 184369


Revision tags: llvmorg-3.3.0, llvmorg-3.3.0-rc3
# dbb3b2f4 31-May-2013 Justin Holewinski <jholewinski@nvidia.com>

[NVPTX] Re-enable support for virtual registers in the final output

Now that 3.3 is branched, we are re-enabling virtual registers to help
iron out bugs before the next release. Some of the post-RA

[NVPTX] Re-enable support for virtual registers in the final output

Now that 3.3 is branched, we are re-enabling virtual registers to help
iron out bugs before the next release. Some of the post-RA passes do
not play well with virtual registers, so we disable them for now. The
needed functionality of the PrologEpilogInserter pass is copied to a
new backend-specific NVPTXPrologEpilog pass.

The test for this commit is not breaking the existing tests.

llvm-svn: 182998

show more ...


Revision tags: llvmorg-3.3.0-rc2, llvmorg-3.3.0-rc1
# 0497ab14 30-Mar-2013 Justin Holewinski <jholewinski@nvidia.com>

[NVPTX] Run clang-format on all NVPTX sources.

Hopefully this resolves any outstanding style issues and gives us
an automated way of ensuring we conform to the style guidelines.

llvm-svn: 178415


# 8da87163 21-Feb-2013 Eli Bendersky <eliben@google.com>

Move the eliminateCallFramePseudoInstr method from TargetRegisterInfo
to TargetFrameLowering, where it belongs. Incidentally, this allows us
to delete some duplicated (and slightly different!) code i

Move the eliminateCallFramePseudoInstr method from TargetRegisterInfo
to TargetFrameLowering, where it belongs. Incidentally, this allows us
to delete some duplicated (and slightly different!) code in TRI.

There are potentially other layering problems that can be cleaned up
as a result, or in a similar manner.

The refactoring was OK'd by Anton Korobeynikov on llvmdev.

Note: this touches the target interfaces, so out-of-tree targets may
be affected.

llvm-svn: 175788

show more ...


# be8dc649 12-Feb-2013 Justin Holewinski <jholewinski@nvidia.com>

[NVPTX] Disable vector registers

Vectors were being manually scalarized by the backend. Instead,
let the target-independent code do all of the work. The manual
scalarization was from a time before

[NVPTX] Disable vector registers

Vectors were being manually scalarized by the backend. Instead,
let the target-independent code do all of the work. The manual
scalarization was from a time before good target-independent support
for scalarization in LLVM. However, this forces us to specially-handle
vector loads and stores, which we can turn into PTX instructions that
produce/consume multiple operands.

llvm-svn: 174968

show more ...


# df782d22 31-Jan-2013 Chad Rosier <mcrosier@apple.com>

[PEI] Pass the frame index operand number to the eliminateFrameIndex function.
Each target implementation was needlessly recomputing the index.
Part of rdar://13076458

llvm-svn: 174083


Revision tags: llvmorg-3.2.0, llvmorg-3.2.0-rc3
# ed0881b2 03-Dec-2012 Chandler Carruth <chandlerc@gmail.com>

Use the new script to sort the includes of every file under lib.

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module

Use the new script to sort the includes of every file under lib.

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.

Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]

llvm-svn: 169131

show more ...


Revision tags: llvmorg-3.2.0-rc2, llvmorg-3.2.0-rc1
# 009b1c1c 06-Jun-2012 Benjamin Kramer <benny.kra@googlemail.com>

Round 2 of dead private variable removal.

LLVM is now -Wunused-private-field clean except for
- lib/MC/MCDisassembler/Disassembler.h. Not sure why it keeps all those unaccessible fields.
- gtest.

l

Round 2 of dead private variable removal.

LLVM is now -Wunused-private-field clean except for
- lib/MC/MCDisassembler/Disassembler.h. Not sure why it keeps all those unaccessible fields.
- gtest.

llvm-svn: 158096

show more ...


# bdf39a46 24-May-2012 Craig Topper <craig.topper@gmail.com>

Convert assert(0) to llvm_unreachable.

llvm-svn: 157380


Revision tags: llvmorg-3.1.0, llvmorg-3.1.0-rc3
# ae556d3e 04-May-2012 Justin Holewinski <jholewinski@nvidia.com>

This patch adds a new NVPTX back-end to LLVM which supports code generation for NVIDIA PTX 3.0. This back-end will (eventually) replace the current PTX back-end, while maintaining compatibility with

This patch adds a new NVPTX back-end to LLVM which supports code generation for NVIDIA PTX 3.0. This back-end will (eventually) replace the current PTX back-end, while maintaining compatibility with it.

The new target machines are:

nvptx (old ptx32) => 32-bit PTX
nvptx64 (old ptx64) => 64-bit PTX

The sources are based on the internal NVIDIA NVPTX back-end, and
contain more functionality than the current PTX back-end currently
provides.

NV_CONTRIB

llvm-svn: 156196

show more ...


12