summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Target/MBlaze/TargetInfo
Commit message (Collapse)AuthorAgeFilesLines
* Remove the mblaze backend from llvm.Rafael Espindola2013-07-254-65/+0
| | | | | | Approval in here http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/064169.html llvm-svn: 187145
* Move all of the header files which are involved in modelling the LLVM IRChandler Carruth2013-01-021-1/+1
| | | | | | | | | | | | | | | | | | | | | into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
* LLVMBuild: Remove trailing newline, which irked me.Daniel Dunbar2011-12-121-1/+0
| | | | llvm-svn: 146409
* build/CMake: Finish removal of add_llvm_library_dependencies.Daniel Dunbar2011-11-291-6/+0
| | | | llvm-svn: 145420
* build: Attempt to rectify inconsistencies between CMake and LLVMBuild ↵Daniel Dunbar2011-11-121-1/+1
| | | | | | | | versions of explicit dependencies. - The hope is that we have a tool/test to verify these are accurate (and tight) soon. llvm-svn: 144444
* build: Add initial cut at LLVMBuild.txt files.Daniel Dunbar2011-11-031-0/+24
| | | | llvm-svn: 143634
* Move TargetRegistry and TargetSelect from Target to Support where they belong.Evan Cheng2011-08-241-1/+1
| | | | | | These are strictly utilities for registering targets and components. llvm-svn: 138450
* Actually finish switching to the new system for Target sublibraryChandler Carruth2011-08-011-1/+1
| | | | | | | | | | | TableGen deps introduced in r136023. This completes the fixing that dgregor started in r136621. Sorry for missing these the first time around. This should fix some of the random race-condition failures people are still seeing with CMake. llvm-svn: 136643
* Rewrite the CMake build to use explicit dependencies between libraries,Chandler Carruth2011-07-291-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | specified in the same file that the library itself is created. This is more idiomatic for CMake builds, and also allows us to correctly specify dependencies that are missed due to bugs in the GenLibDeps perl script, or change from compiler to compiler. On Linux, this returns CMake to a place where it can relably rebuild several targets of LLVM. I have tried not to change the dependencies from the ones in the current auto-generated file. The only places I've really diverged are in places where I was seeing link failures, and added a dependency. The goal of this patch is not to start changing the dependencies, merely to move them into the correct location, and an explicit form that we can control and change when necessary. This also removes a serialization point in the build because we don't have to scan all the libraries before we begin building various tools. We no longer have a step of the build that regenerates a file inside the source tree. A few other associated cleanups fall out of this. This isn't really finished yet though. After talking to dgregor he urged switching to a single CMake macro to construct libraries with both sources and dependencies in the arguments. Migrating from the two macros to that style will be a follow-up patch. Also, llvm-config is still generated with GenLibDeps.pl, which means it still has slightly buggy dependencies. The internal CMake 'llvm-config-like' macro uses the correct explicitly specified dependencies however. A future patch will switch llvm-config generation (when using CMake) to be based on these deps as well. This may well break Windows. I'm getting a machine set up now to dig into any failures there. If anyone can chime in with problems they see or ideas of how to solve them for Windows, much appreciated. llvm-svn: 136433
* Recommit 116986 with capitalization typo fixed.Wesley Peck2010-10-211-1/+2
| | | | llvm-svn: 116993
* Reverting the commit 116986. It was breaking the build on llvm-x86_64-linux ↵Wesley Peck2010-10-211-2/+1
| | | | | | | | | though it compiles on OS X. I'll ensure that it builds on a linux machine before committing again. llvm-svn: 116991
* Major update of the MicroBlaze backend. The new features are:Wesley Peck2010-10-211-1/+2
| | | | | | | | | | | | | | | | | | | | 1. A delay slot filler that searches for valid instructions to fill the delay slot with. Previously NOPs would always be inserted into delay slots. 2. Support for MC based instruction printer added. 3. Support for MC based machine code generation and ELF file generation. ELF file generation does not yet completely work as much of the ELF support infrastructure is still x86/x86-64 specific. 4. General clean up of the MBlaze backend code. Much of the tablegen code has been cleanup and simplified. Bug Fixes: 1. Removed duplicate periods from subtarget feature descriptions. 2. Many of the instructions had bad machine code information in the tablegen files. Much of this has been fixed. llvm-svn: 116986
* Adding the MicroBlaze backend.Wesley Peck2010-02-233-0/+41
The MicroBlaze is a highly configurable 32-bit soft-microprocessor for use on Xilinx FPGAs. For more information see: http://www.xilinx.com/tools/microblaze.htm http://en.wikipedia.org/wiki/MicroBlaze The current LLVM MicroBlaze backend generates assembly which can be compiled using the an appropriate binutils assembler. llvm-svn: 96969
OpenPOWER on IntegriCloud