mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-25 12:12:47 +01:00
a571c5d5d3
The first problem to fix is to stop creating synthetic *Table_gen targets next to all of the LLVM libraries. These had no real effect as CMake specifies that add_custom_command(OUTPUT ...) directives (what the 'tablegen(...)' stuff expands to) are implicitly added as dependencies to all the rules in that CMakeLists.txt. These synthetic rules started to cause problems as we started more and more heavily using tablegen files from *subdirectories* of the one where they were generated. Within those directories, the set of tablegen outputs was still available and so these synthetic rules added them as dependencies of those subdirectories. However, they were no longer properly associated with the custom command to generate them. Most of the time this "just worked" because something would get to the parent directory first, and run tablegen there. Once run, the files existed and the build proceeded happily. However, as more and more subdirectories have started using this, the probability of this failing to happen has increased. Recently with the MC refactorings, it became quite common for me when touching a large enough number of targets. To add insult to injury, several of the backends *tried* to fix this by adding explicit dependencies back to the parent directory's tablegen rules, but those dependencies didn't work as expected -- they weren't forming a linear chain, they were adding another thread in the race. This patch removes these synthetic rules completely, and adds a much simpler function to declare explicitly that a collection of tablegen'ed files are referenced by other libraries. From that, we can add explicit dependencies from the smaller libraries (such as every architectures Desc library) on this and correctly form a linear sequence. All of the backends are updated to use it, sometimes replacing the existing attempt at adding a dependency, sometimes adding a previously missing dependency edge. Please let me know if this causes any problems, but it fixes a rather persistent and problematic source of build flakiness on our end. llvm-svn: 136023 |
||
|---|---|---|
| .. | ||
| MCTargetDesc | ||
| TargetInfo | ||
| CellSDKIntrinsics.td | ||
| CMakeLists.txt | ||
| Makefile | ||
| README.txt | ||
| SPU64InstrInfo.td | ||
| SPU128InstrInfo.td | ||
| SPU.h | ||
| SPU.td | ||
| SPUAsmPrinter.cpp | ||
| SPUCallingConv.td | ||
| SPUFrameLowering.cpp | ||
| SPUFrameLowering.h | ||
| SPUHazardRecognizers.cpp | ||
| SPUHazardRecognizers.h | ||
| SPUInstrBuilder.h | ||
| SPUInstrFormats.td | ||
| SPUInstrInfo.cpp | ||
| SPUInstrInfo.h | ||
| SPUInstrInfo.td | ||
| SPUISelDAGToDAG.cpp | ||
| SPUISelLowering.cpp | ||
| SPUISelLowering.h | ||
| SPUMachineFunction.h | ||
| SPUMathInstr.td | ||
| SPUNodes.td | ||
| SPUNopFiller.cpp | ||
| SPUOperands.td | ||
| SPURegisterInfo.cpp | ||
| SPURegisterInfo.h | ||
| SPURegisterInfo.td | ||
| SPURegisterNames.h | ||
| SPUSchedule.td | ||
| SPUSelectionDAGInfo.cpp | ||
| SPUSelectionDAGInfo.h | ||
| SPUSubtarget.cpp | ||
| SPUSubtarget.h | ||
| SPUTargetMachine.cpp | ||
| SPUTargetMachine.h | ||
//===- README.txt - Notes for improving CellSPU-specific code gen ---------===//
This code was contributed by a team from the Computer Systems Research
Department in The Aerospace Corporation:
- Scott Michel (head bottle washer and much of the non-floating point
instructions)
- Mark Thomas (floating point instructions)
- Michael AuYeung (intrinsics)
- Chandler Carruth (LLVM expertise)
- Nehal Desai (debugging, i32 operations, RoadRunner SPU expertise)
Some minor fixes added by Kalle Raiskila.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR
OTHERWISE. IN NO EVENT SHALL THE AEROSPACE CORPORATION BE LIABLE FOR DAMAGES
OF ANY KIND OR NATURE WHETHER BASED IN CONTRACT, TORT, OR OTHERWISE ARISING
OUT OF OR IN CONNECTION WITH THE USE OF THE SOFTWARE INCLUDING, WITHOUT
LIMITATION, DAMAGES RESULTING FROM LOST OR CONTAMINATED DATA, LOST PROFITS OR
REVENUE, COMPUTER MALFUNCTION, OR FOR ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL,
OR PUNITIVE DAMAGES, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES OR
SUCH DAMAGES ARE FORESEEABLE.
---------------------------------------------------------------------------
--WARNING--:
--WARNING--: The CellSPU work is work-in-progress and "alpha" quality code.
--WARNING--:
If you are brave enough to try this code or help to hack on it, be sure
to add 'spu' to configure's --enable-targets option, e.g.:
./configure <your_configure_flags_here> \
--enable-targets=x86,x86_64,powerpc,spu
---------------------------------------------------------------------------
TODO:
* Create a machine pass for performing dual-pipeline scheduling specifically
for CellSPU, and insert branch prediction instructions as needed.
* i32 instructions:
* i32 division (work-in-progress)
* i64 support (see i64operations.c test harness):
* shifts and comparison operators: done
* sign and zero extension: done
* addition: done
* subtraction: needed
* multiplication: done
* i128 support:
* zero extension, any extension: done
* sign extension: done
* arithmetic operators (add, sub, mul, div): needed
* logical operations (and, or, shl, srl, sra, xor, nor, nand): needed
* or: done
* f64 support
* Comparison operators:
SETOEQ unimplemented
SETOGT unimplemented
SETOGE unimplemented
SETOLT unimplemented
SETOLE unimplemented
SETONE unimplemented
SETO done (lowered)
SETUO done (lowered)
SETUEQ unimplemented
SETUGT unimplemented
SETUGE unimplemented
SETULT unimplemented
SETULE unimplemented
SETUNE unimplemented
* LLVM vector suport
* VSETCC needs to be implemented. It's pretty straightforward to code, but
needs implementation.
* Intrinsics
* spu.h instrinsics added but not tested. Need to have an operational
llvm-spu-gcc in order to write a unit test harness.
===-------------------------------------------------------------------------===