- Currently this leaves us with less build system support (e.g., installing man pages) for the docs than is desired. I'm working on fixing this, but it may take a while. If someone finds this particularly egregious let me know and I will prioritize it.
llvm-svn: 156389
While making lld build under the tools directory I decided to refactor how this
works.
There is now a macro, add_llvm_external_project, which takes the name of the
expected subdirectory. This sets up two CMake options.
* LLVM_EXTERNAL_${NAME}_SOURCE_DIR
This is the path to the source. It defaults to
${CMAKE_CURRENT_SOURCE_DIR}/${name}.
* LLVM_EXTERNAL_${NAME}_BUILD
Enable and disable building the tool as part of LLVM.
I chose LLVM_EXTERNAL_${NAME} as a prefix so they all show up together in the
GUI.
llvm-svn: 155654
- FlatArrayMap. Very simple map container that uses flat array inside.
- MultiImplMap. Map container interface, that has two modes, one for small amount of elements and one for big amount.
- SmallMap. SmallMap is DenseMap compatible MultiImplMap. It uses FlatArrayMap for small mode, and DenseMap for big mode.
Also added unittests for new classes and update for ProgrammersManual.
For more details about new classes see ProgrammersManual and comments in sourcecode.
llvm-svn: 155557
llvm-ld is no longer useful and causes confusion and so it is being removed.
* Does not work very well on Windows because it must call a gcc like driver to
assemble and link.
* Has lots of hard coded paths which are wrong on many systems.
* Does not understand most of ld's options.
* Can be partially replaced by llvm-link | opt | {llc | as, llc -filetype=obj} |
ld, or fully replaced by Clang.
I know of no production use of llvm-ld, and hacking use should be
replaced by Clang's driver.
llvm-svn: 155147
- Work in progress, this is mostly important because it lets us incrementally migrate the remaining documentation.
- Lots of styling, editing, and integration work yet to come…
- PR12589
llvm-svn: 155133
through the use of 'fpmath' metadata. Currently this only provides a 'fpaccuracy'
value, which may be a number in ULPs or the keyword 'fast', however the intent is
that this will be extended with additional information about NaN's, infinities
etc later. No optimizations have been hooked up to this so far.
llvm-svn: 154822
thinking of generalizing it to be able to specify other freedoms beyond accuracy
(such as that NaN's don't have to be respected). I'd like the 3.1 release (the
first one with this metadata) to have the more generic name already rather than
having to auto-upgrade it in 3.2.
llvm-svn: 154744
