Aren/NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Import LLVM 3.5svn r209886.

Browse Source
This commit is contained in:
joerg 2014-05-30 18:09:54 +00:00
parent eaa06116b6
commit 4b590142ed
4355 changed files with 315897 additions and 158487 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
external/bsd/llvm/dist/llvm/.arcconfig vendored
View File

@ -1,4 +1,4 @@
{
"project_id" : "llvm",
"conduit_uri" : "http://llvm-reviews.chandlerc.com/"
"conduit_uri" : "http://reviews.llvm.org/"
}

1
external/bsd/llvm/dist/llvm/.clang-format vendored
View File

@ -1 +1,2 @@
BasedOnStyle: LLVM

1
external/bsd/llvm/dist/llvm/.gitignore vendored
View File

@ -37,7 +37,6 @@ compile_commands.json
#==============================================================================#
# External projects that are tracked independently.
projects/*
!projects/sample
!projects/CMakeLists.txt
!projects/Makefile
# Clang, which is tracked independently.

57
external/bsd/llvm/dist/llvm/CMakeLists.txt vendored
View File

@ -27,9 +27,10 @@ set(CMAKE_MODULE_PATH
set(LLVM_VERSION_MAJOR 3)
set(LLVM_VERSION_MINOR 5)
set(LLVM_VERSION_PATCH 0)
if (NOT PACKAGE_VERSION)
set(PACKAGE_VERSION "${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}svn")
set(PACKAGE_VERSION "${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH}svn")
endif()
option(LLVM_INSTALL_TOOLCHAIN_ONLY "Only include toolchain files in the 'install' target." OFF)
@ -60,11 +61,14 @@ set(CPACK_PACKAGE_INSTALL_DIRECTORY "LLVM")
set(CPACK_PACKAGE_VENDOR "LLVM")
set(CPACK_PACKAGE_VERSION_MAJOR ${LLVM_VERSION_MAJOR})
set(CPACK_PACKAGE_VERSION_MINOR ${LLVM_VERSION_MINOR})
set(CPACK_PACKAGE_VERSION_PATCH ${LLVM_VERSION_PATCH})
set(CPACK_PACKAGE_VERSION ${PACKAGE_VERSION})
set(CPACK_RESOURCE_FILE_LICENSE "${CMAKE_CURRENT_SOURCE_DIR}/LICENSE.TXT")
if(WIN32 AND NOT UNIX)
set(CPACK_PACKAGE_INSTALL_REGISTRY_KEY "LLVM")
set(CPACK_PACKAGE_ICON "${CMAKE_CURRENT_SOURCE_DIR}\\\\cmake\\\\nsis_logo.bmp")
set(CPACK_NSIS_MUI_ICON "${CMAKE_CURRENT_SOURCE_DIR}\\\\cmake\\\\nsis_icon.ico")
set(CPACK_NSIS_MUI_UNIICON "${CMAKE_CURRENT_SOURCE_DIR}\\\\cmake\\\\nsis_icon.ico")
set(CPACK_NSIS_MODIFY_PATH "ON")
set(CPACK_NSIS_ENABLE_UNINSTALL_BEFORE_INSTALL "ON")
set(CPACK_NSIS_EXTRA_INSTALL_COMMANDS
@ -194,11 +198,11 @@ option(LLVM_ENABLE_PIC "Build Position-Independent Code" ON)
# MSVC has a gazillion warnings with this.
if( MSVC )
option(LLVM_ENABLE_WARNINGS "Enable compiler warnings." OFF)
else( MSVC )
else()
option(LLVM_ENABLE_WARNINGS "Enable compiler warnings." ON)
endif()
option(LLVM_ENABLE_CXX11 "Compile with C++11 enabled." ON)
option(LLVM_ENABLE_CXX1Y "Compile with C++1y enabled." OFF)
option(LLVM_ENABLE_LIBCXX "Use libc++ if available." OFF)
option(LLVM_ENABLE_PEDANTIC "Compile with pedantic enabled." ON)
option(LLVM_ENABLE_WERROR "Fail and stop if a warning is triggered." OFF)
@ -268,6 +272,8 @@ option(LLVM_INCLUDE_TOOLS "Generate build targets for the LLVM tools." ON)
option(LLVM_BUILD_TOOLS
"Build the LLVM tools. If OFF, just generate build targets." ON)
option(LLVM_INCLUDE_UTILS "Generate build targets for the LLVM utils." ON)
option(LLVM_BUILD_RUNTIME
"Build the LLVM runtime libraries." ON)
option(LLVM_BUILD_EXAMPLES
@ -280,7 +286,8 @@ option(LLVM_INCLUDE_TESTS "Generate build targets for the LLVM unit tests." ON)
option (LLVM_BUILD_DOCS "Build the llvm documentation." OFF)
option (LLVM_INCLUDE_DOCS "Generate build targets for llvm documentation." ON)
option (LLVM_ENABLE_DOXYGEN "Use doxygen to generate llvm documentation." OFF)
option (LLVM_ENABLE_DOXYGEN "Use doxygen to generate llvm API documentation." OFF)
option (LLVM_ENABLE_SPHINX "Use Sphinx to generate llvm documentation." OFF)
option (LLVM_BUILD_EXTERNAL_COMPILER_RT
"Build compiler-rt as an external project." OFF)
@ -443,6 +450,9 @@ if (APPLE)
else(UNIX)
if(NOT DEFINED CMAKE_INSTALL_RPATH)
set(CMAKE_INSTALL_RPATH "\$ORIGIN/../lib")
if (${CMAKE_SYSTEM_NAME} MATCHES FreeBSD)
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,-z,origin")
endif()
endif(NOT DEFINED CMAKE_INSTALL_RPATH)
endif()
@ -484,12 +494,20 @@ add_subdirectory(include/llvm)
add_subdirectory(lib)
add_subdirectory(utils/FileCheck)
add_subdirectory(utils/FileUpdate)
add_subdirectory(utils/count)
add_subdirectory(utils/not)
add_subdirectory(utils/llvm-lit)
add_subdirectory(utils/yaml-bench)
if( LLVM_INCLUDE_UTILS )
add_subdirectory(utils/FileCheck)
add_subdirectory(utils/FileUpdate)
add_subdirectory(utils/PerfectShuffle)
add_subdirectory(utils/count)
add_subdirectory(utils/not)
add_subdirectory(utils/llvm-lit)
add_subdirectory(utils/yaml-bench)
else()
if ( LLVM_INCLUDE_TESTS )
message(FATAL_ERROR "Including tests when not building utils will not work.
Either set LLVM_INCLUDE_UTILS to On, or set LLVM_INCLDE_TESTS to Off.")
endif()
endif()
if(LLVM_INCLUDE_TESTS)
add_subdirectory(utils/unittest)
@ -497,6 +515,15 @@ endif()
add_subdirectory(projects)
option(WITH_POLLY "Build LLVM with Polly" ON)
option(LINK_POLLY_INTO_TOOLS "Static link Polly into tools" OFF)
if(WITH_POLLY)
if(NOT EXISTS ${LLVM_MAIN_SRC_DIR}/tools/polly/CMakeLists.txt)
set(WITH_POLLY OFF)
endif()
endif(WITH_POLLY)
if( LLVM_INCLUDE_TOOLS )
add_subdirectory(tools)
endif()
@ -559,13 +586,3 @@ if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
PATTERN ".svn" EXCLUDE
)
endif()
# Workaround for MSVS10 to avoid the Dialog Hell
# FIXME: This could be removed with future version of CMake.
if(MSVC_VERSION EQUAL 1600)
set(LLVM_SLN_FILENAME "${CMAKE_CURRENT_BINARY_DIR}/LLVM.sln")
if( EXISTS "${LLVM_SLN_FILENAME}" )
file(APPEND "${LLVM_SLN_FILENAME}" "\n# This should be regenerated!\n")
endif()
endif()

6
external/bsd/llvm/dist/llvm/CODE_OWNERS.TXT vendored
View File

@ -29,6 +29,10 @@ N: Evan Cheng
E: evan.cheng@apple.com
D: ARM target, parts of code generator not covered by someone else
N: Renato Golin
E: renato.golin@linaro.org
D: ARM Linux support
N: Eric Christopher
E: echristo@gmail.com
D: Debug Information, autotools/configure/make build, inline assembly
@ -92,7 +96,7 @@ W: http://nondot.org/~sabre/
D: Everything not covered by someone else
N: Tim Northover
E: Tim.Northover@arm.com
E: t.p.northover@gmail.com
D: AArch64 backend
N: Jakob Olesen

17
external/bsd/llvm/dist/llvm/CREDITS.TXT vendored
View File

@ -107,6 +107,10 @@ N: Rafael Avila de Espindola
E: rafael.espindola@gmail.com
D: The ARM backend
N: Dave Estes
E: cestes@codeaurora.org
D: AArch64 machine description for Cortex-A53
N: Alkis Evlogimenos
E: alkis@evlogimenos.com
D: Linear scan register allocator, many codegen improvements, Java frontend
@ -132,6 +136,7 @@ W: http://www-src.lip6.fr/homepages/Nicolas.Geoffray/
D: PPC backend fixes for Linux
N: Louis Gerbarg
E: lgg@apple.com
D: Portions of the PowerPC backend
N: Saem Ghani
@ -161,10 +166,12 @@ D: Improvements for space efficiency
N: James Grosbach
E: grosbach@apple.com
I: grosbach
D: SjLj exception handling support
D: General fixes and improvements for the ARM back-end
D: MCJIT
D: ARM integrated assembler and assembly parser
D: Led effort for the backend formerly known as ARM64
N: Lang Hames
E: lhames@gmail.com
@ -338,6 +345,10 @@ D: LTO tool, PassManager rewrite, Loop Pass Manager, Loop Rotate
D: GCC PCH Integration (llvm-gcc), llvm-gcc improvements
D: Optimizer improvements, Loop Index Split
N: Ana Pazos
E: apazos@codeaurora.org
D: Fixes and improvements to the AArch64 backend
N: Wesley Peck
E: peckw@wesleypeck.com
W: http://wesleypeck.com/
@ -367,8 +378,10 @@ D: ARM calling conventions rewrite, hard float support
N: Chad Rosier
E: mcrosier@codeaurora.org
D: ARM fast-isel improvements
D: Performance monitoring
I: mcrosier
D: AArch64 fast instruction selection pass
D: Fixes and improvements to the ARM fast-isel pass
D: Fixes and improvements to the AArch64 backend
N: Nadav Rotem
E: nrotem@apple.com

1
external/bsd/llvm/dist/llvm/LICENSE.TXT vendored
View File

@ -63,7 +63,6 @@ Program Directory
------- ---------
Autoconf llvm/autoconf
llvm/projects/ModuleMaker/autoconf
llvm/projects/sample/autoconf
Google Test llvm/utils/unittest/googletest
OpenBSD regex llvm/lib/Support/{reg*, COPYRIGHT.regex}
pyyaml tests llvm/test/YAMLParser/{*.data, LICENSE.TXT}

5
external/bsd/llvm/dist/llvm/Makefile vendored
View File

@ -112,6 +112,11 @@ cross-compile-build-tools:
cd BuildTools ; \
unset CFLAGS ; \
unset CXXFLAGS ; \
AR=$(BUILD_AR) ; \
AS=$(BUILD_AS) ; \
LD=$(BUILD_LD) ; \
CC=$(BUILD_CC) ; \
CXX=$(BUILD_CXX) ; \
unset SDKROOT ; \
unset UNIVERSAL_SDK_PATH ; \
configure_opts= ; \

10
external/bsd/llvm/dist/llvm/Makefile.config.in vendored
View File

@ -17,6 +17,8 @@ LLVMPackageName := @PACKAGE_TARNAME@
LLVMVersion := @PACKAGE_VERSION@
LLVM_VERSION_MAJOR := @LLVM_VERSION_MAJOR@
LLVM_VERSION_MINOR := @LLVM_VERSION_MINOR@
LLVM_VERSION_PATCH := @LLVM_VERSION_PATCH@
LLVM_VERSION_SUFFIX := @LLVM_VERSION_SUFFIX@
LLVM_CONFIGTIME := @LLVM_CONFIGTIME@
###########################################################################
@ -244,12 +246,16 @@ RDYNAMIC := @RDYNAMIC@
#ENABLE_LIBCPP = 0
ENABLE_LIBCPP = @ENABLE_LIBCPP@
# When ENABLE_CXX11 is enabled, LLVM uses c++11 mode by default to build.
ENABLE_CXX11 = @ENABLE_CXX11@
# When ENABLE_CXX1Y is enabled, LLVM uses c++1y mode by default to build.
# Otherwise it uses the baseline c++11.
ENABLE_CXX1Y = @ENABLE_CXX1Y@
# When ENABLE_SPLIT_DWARF is enabled, LLVM uses -gfission to build in debug mode.
ENABLE_SPLIT_DWARF = @ENABLE_SPLIT_DWARF@
# When enabled, clang will have plugin support.
CLANG_PLUGIN_SUPPORT = @CLANG_PLUGIN_SUPPORT@
# When ENABLE_CLANG_ARCMT is enabled, clang will have ARCMigrationTool.
ENABLE_CLANG_ARCMT = @ENABLE_CLANG_ARCMT@

50
external/bsd/llvm/dist/llvm/Makefile.rules vendored
View File

@ -319,8 +319,16 @@ ifeq ($(ENABLE_LIBCPP),1)
LD.Flags += -stdlib=libc++
endif
ifeq ($(ENABLE_CXX11),1)
CXX.Flags += -std=c++11
ifeq ($(ENABLE_CXX1Y),1)
CXX.Flags += -std=c++1y
else
ifeq ($(HOST_OS), $(filter $(HOST_OS), Cygwin MingW))
# MinGW and Cygwin are a bit stricter and lack things like
# 'strdup', 'stricmp', etc in c++11 mode.
CXX.Flags += -std=gnu++11
else
CXX.Flags += -std=c++11
endif
endif
ifeq ($(ENABLE_WERROR),1)
@ -679,13 +687,13 @@ ifeq ($(HOST_OS),HP-UX)
CompileCommonOpts := -D_REENTRANT -D_HPUX_SOURCE
endif
# If we are building a universal binary on Mac OS/X, pass extra options. This
# If we are building a universal binary on Mac OS X, pass extra options. This
# is useful to people that want to link the LLVM libraries into their universal
# apps.
#
# The following can be optionally specified:
# UNIVERSAL_SDK_PATH variable can be specified as a path to the SDK to use.
# For Mac OS/X 10.4 Intel machines, the traditional one is:
# For Mac OS X 10.4 Intel machines, the traditional one is:
# UNIVERSAL_SDK_PATH=/Developer/SDKs/MacOSX10.4u.sdk/
# UNIVERSAL_ARCH can be optionally specified to be a list of architectures
# to build for, e.g. UNIVERSAL_ARCH="i386 ppc ppc64". This defaults to
@ -785,7 +793,7 @@ else
Ranlib = ranlib
endif
AliasTool = ln -s
AliasTool = ln -sf
#----------------------------------------------------------
# Get the list of source files and compute object file
@ -1055,8 +1063,9 @@ ifeq ($(HOST_OS), $(filter $(HOST_OS), Cygwin MingW))
LLVMLibsOptions += -Wl,--enable-auto-import,--enable-runtime-pseudo-reloc \
-L $(SharedLibDir)
endif
LLVMLibsOptions += -lLLVM-$(LLVMVersion)
LLVMLibsPaths += $(SharedLibDir)/$(SharedPrefix)LLVM-$(LLVMVersion)$(SHLIBEXT)
LLVM_SO_NAME = LLVM-$(LLVM_VERSION_MAJOR).$(LLVM_VERSION_MINOR)$(LLVM_VERSION_SUFFIX)
LLVMLibsOptions += -l$(LLVM_SO_NAME)
LLVMLibsPaths += $(SharedLibDir)/$(SharedPrefix)$(LLVM_SO_NAME)$(SHLIBEXT)
else
ifndef NO_LLVM_CONFIG
@ -1149,15 +1158,19 @@ ifdef LIBRARYNAME
# Make sure there isn't any extraneous whitespace on the LIBRARYNAME option
LIBRARYNAME := $(strip $(LIBRARYNAME))
LIBRARYALIASNAME := $(strip $(LIBRARYALIASNAME))
ifdef LOADABLE_MODULE
BaseLibName.A := $(LIBRARYNAME).a
BaseLibName.SO := $(LIBRARYNAME)$(SHLIBEXT)
BaseAliasName.SO := $(LIBRARYALIASNAME)$(SHLIBEXT)
else
BaseLibName.A := lib$(LIBRARYNAME).a
BaseLibName.SO := $(SharedPrefix)$(LIBRARYNAME)$(SHLIBEXT)
BaseAliasName.SO := $(SharedPrefix)$(LIBRARYALIASNAME)$(SHLIBEXT)
endif
LibName.A := $(LibDir)/$(BaseLibName.A)
LibName.SO := $(SharedLibDir)/$(BaseLibName.SO)
AliasName.SO := $(SharedLibDir)/$(BaseAliasName.SO)
LibName.O := $(LibDir)/$(LIBRARYNAME).o
#---------------------------------------------------------
@ -1168,7 +1181,12 @@ LibName.O := $(LibDir)/$(LIBRARYNAME).o
#---------------------------------------------------------
ifdef SHARED_LIBRARY
all-local:: $(LibName.SO)
all-local:: $(AliasName.SO)
$(AliasName.SO): $(LibName.SO)
ifdef SHARED_ALIAS
$(Verb) $(AliasTool) $(BaseLibName.SO) $(AliasName.SO)
endif
ifdef EXPORTED_SYMBOL_FILE
$(LibName.SO): $(NativeExportsFile)
@ -1211,16 +1229,24 @@ else
DestSharedLibDir := $(DESTDIR)$(PROJ_libdir)
endif
DestSharedLib := $(DestSharedLibDir)/$(BaseLibName.SO)
DestSharedAlias := $(DestSharedLibDir)/$(BaseAliasName.SO)
install-local:: $(DestSharedLib)
$(DestSharedLib): $(LibName.SO) $(DestSharedLibDir)
$(Echo) Installing $(BuildMode) Shared Library $(DestSharedLib)
$(Verb) $(INSTALL) $(LibName.SO) $(DestSharedLib)
ifdef SHARED_ALIAS
$(Echo) Creating alias from $(DestSharedLib) to $(DestSharedAlias)
$(Verb) $(AliasTool) $(BaseLibName.SO) $(DestSharedAlias)
endif
uninstall-local::
$(Echo) Uninstalling $(BuildMode) Shared Library $(DestSharedLib)
-$(Verb) $(RM) -f $(DestSharedLib)
ifdef SHARED_ALIAS
-$(Verb) $(RM) -f $(DestSharedAlias)
endif
endif
endif
@ -1696,8 +1722,14 @@ $(ObjDir)/%GenDFAPacketizer.inc.tmp : %.td $(ObjDir)/.dir $(LLVM_TBLGEN)
$(Echo) "Building $(<F) DFA packetizer tables with tblgen"
$(Verb) $(LLVMTableGen) -gen-dfa-packetizer -o $(call SYSPATH, $@) $<
# Dump all the records to <target>.td.expanded. This is useful for debugging.
$(TARGET:%=%.td.expanded): \
%.td.expanded : %.td $(LLVM_TBLGEN)
$(Echo) "Building a fully expanded version of $(<F)"
$(Verb) $(LLVMTableGen) -o $(call SYSPATH, $@) $<
clean-local::
-$(Verb) $(RM) -f $(INCFiles)
-$(Verb) $(RM) -f $(INCFiles) $(TARGET).td.expanded
endif # TARGET

1
external/bsd/llvm/dist/llvm/README.txt vendored
View File

@ -15,4 +15,3 @@ documentation setup.
If you're writing a package for LLVM, see docs/Packaging.rst for our
suggestions.

35
external/bsd/llvm/dist/llvm/autoconf/README.TXT vendored
View File

@ -1,38 +1,3 @@
Upgrading Libtool
===============================================================================
If you are in the mood to upgrade libtool, you must do the following:
1. Get the new version of libtool and put it in <SRC>
2. configure/build/install libtool with --prefix=<PFX>
3. Copy <SRC>/ltdl.m4 to llvm/autoconf/m4
4. Copy <PFX>/share/aclocal/libtool.m4 to llvm/autoconf/m4/libtool.m4
5. Copy <PFX>/share/libtool/ltmain.sh to llvm/autoconf/ltmain.sh
6. Copy <PFX>/share/libtool/libltdl/ltdl.c to llvm/lib/System
7. Copy <PFX>/share/libtool/libltdl/ltdl.h to llvm/lib/System
8. Edit the ltdl.h file to #include "llvm/Config/config.h" at the very top. You
might also need to resolve some compiler warnings (typically about
comparison of signed vs. unsigned values). But, you won't find out about
those until you build LLVM (step 13).
9. Edit the llvm/autoconf/m4/libtool.m4 file so that:
a) in AC_PROB_LIBTOOL macro, the value of LIBTOOL is set to
$(top_builddir)/mklib, not $(top_builddir)/libtool
b) in AC_LIBTOOL_SETUP macro, the variable default_ofile is set to
"mklib" instead of "libtool"
c) s/AC_ENABLE_SHARED_DEFAULT/enable_shared_default/g
d) s/AC_ENABLE_STATIC_DEFAULT/enable_static_default/g
e) s/AC_ENABLE_FAST_INSTALL_DEFAULT/enable_fast_install_default/g
10. Run "autoupdate libtool.m4 ltdl.m4" in the llvm/autoconf/m4 directory.
This should correctly update the macro definitions in the libtool m4
files to match the version of autoconf that LLVM uses. This converts
AC_HELP_STRING to AS_HELP_STRING and AC_TRY_LINK to AC_LINK_IFELSE, amongst
other things. You may need to manually adjust the files.
11. Run AutoRegen.sh to get the new macros into configure script
12. If there are any warnings from AutoRegen.sh, go to step 9.
13. Rebuild LLVM, making sure it reconfigures
14. Test the JIT which uses libltdl
15. If it all works, only THEN commit the changes.
Upgrading autoconf
===============================================================================

62
external/bsd/llvm/dist/llvm/autoconf/configure.ac vendored
View File

@ -31,9 +31,22 @@ dnl===
dnl===-----------------------------------------------------------------------===
dnl Initialize autoconf and define the package name, version number and
dnl address for reporting bugs.
AC_INIT([LLVM],[3.5svn],[http://llvm.org/bugs/])
LLVM_DEFINE_SUBST([LLVM_VERSION_MAJOR], [3], [Major version of the LLVM API])
LLVM_DEFINE_SUBST([LLVM_VERSION_MINOR], [5], [Minor version of the LLVM API])
AC_INIT([LLVM],[3.5.0svn],[http://llvm.org/bugs/])
LLVM_VERSION_MAJOR=3
LLVM_VERSION_MINOR=5
LLVM_VERSION_PATCH=0
LLVM_VERSION_SUFFIX=svn
AC_DEFINE_UNQUOTED([LLVM_VERSION_MAJOR], $LLVM_VERSION_MAJOR, [Major version of the LLVM API])
AC_DEFINE_UNQUOTED([LLVM_VERSION_MINOR], $LLVM_VERSION_MINOR, [Minor version of the LLVM API])
AC_DEFINE_UNQUOTED([LLVM_VERSION_PATCH], $LLVM_VERSION_PATCH, [Patch version of the LLVM API])
AC_SUBST([LLVM_VERSION_MAJOR])
AC_SUBST([LLVM_VERSION_MINOR])
AC_SUBST([LLVM_VERSION_PATCH])
AC_SUBST([LLVM_VERSION_SUFFIX])
dnl Provide a copyright substitution and ensure the copyright notice is included
dnl in the output of --version option of the generated configure script.
@ -153,7 +166,6 @@ for i in `ls ${srcdir}/projects`
do
if test -d ${srcdir}/projects/${i} ; then
case ${i} in
sample) AC_CONFIG_SUBDIRS([projects/sample]) ;;
safecode) AC_CONFIG_SUBDIRS([projects/safecode]) ;;
compiler-rt) ;;
test-suite) ;;
@ -407,6 +419,7 @@ AC_CACHE_CHECK([target architecture],[llvm_cv_target_arch],
amd64-* | x86_64-*) llvm_cv_target_arch="x86_64" ;;
sparc*-*) llvm_cv_target_arch="Sparc" ;;
powerpc*-*) llvm_cv_target_arch="PowerPC" ;;
arm64*-*) llvm_cv_target_arch="AArch64" ;;
arm*-*) llvm_cv_target_arch="ARM" ;;
aarch64*-*) llvm_cv_target_arch="AArch64" ;;
mips-* | mips64-*) llvm_cv_target_arch="Mips" ;;
@ -442,6 +455,7 @@ case $host in
amd64-* | x86_64-*) host_arch="x86_64" ;;
sparc*-*) host_arch="Sparc" ;;
powerpc*-*) host_arch="PowerPC" ;;
arm64*-*) host_arch="AArch64" ;;
arm*-*) host_arch="ARM" ;;
aarch64*-*) host_arch="AArch64" ;;
mips-* | mips64-*) host_arch="Mips" ;;
@ -589,19 +603,19 @@ bypass these sanity checks.])])
;;
esac
dnl --enable-cxx11 : check whether or not to use -std=c++11 on the command line
AC_ARG_ENABLE(cxx11,
AS_HELP_STRING([--enable-cxx11],
[Use c++11 if available (default is YES)]),,
dnl --enable-cxx1y : check whether or not to use -std=c++1y on the command line
AC_ARG_ENABLE(cxx1y,
AS_HELP_STRING([--enable-cxx1y],
[Use c++1y if available (default is NO)]),,
enableval=default)
case "$enableval" in
yes) AC_SUBST(ENABLE_CXX11,[1]) ;;
no) AC_SUBST(ENABLE_CXX11,[0]) ;;
default) AC_SUBST(ENABLE_CXX11,[1]);;
*) AC_MSG_ERROR([Invalid setting for --enable-cxx11. Use "yes" or "no"]) ;;
yes) AC_SUBST(ENABLE_CXX1Y,[1]) ;;
no) AC_SUBST(ENABLE_CXX1Y,[0]) ;;
default) AC_SUBST(ENABLE_CXX1Y,[0]);;
*) AC_MSG_ERROR([Invalid setting for --enable-cxx1y. Use "yes" or "no"]) ;;
esac
dnl --enable-fission : check whether or not to use -gsplit-dwarf on the command
dnl --enable-split-dwarf : check whether or not to use -gsplit-dwarf on the command
dnl line
AC_ARG_ENABLE(split-dwarf,
AS_HELP_STRING([--enable-split-dwarf],
@ -628,6 +642,20 @@ case "$enableval" in
*) AC_MSG_ERROR([Invalid setting for --enable-clang-arcmt. Use "yes" or "no"]) ;;
esac
dnl --enable-clang-plugin-support: check whether to enable plugins in clang
clang_plugin_support="yes"
AC_ARG_ENABLE(clang-plugin-support,
AS_HELP_STRING([--enable-clang-plugin-support],
[Enable plugin support in clang (default is YES)]),
clang_plugin_support="$enableval",
enableval="yes")
case "$enableval" in
yes) AC_SUBST(CLANG_PLUGIN_SUPPORT,[1]) ;;
no) AC_SUBST(CLANG_PLUGIN_SUPPORT,[0]) ;;
default) AC_SUBST(CLANG_PLUGIN_SUPPORT,[1]);;
*) AC_MSG_ERROR([Invalid setting for --enable-clang-plugin-support. Use "yes" or "no"]) ;;
esac
dnl --enable-clang-static-analyzer: check whether to enable static-analyzer
clang_static_analyzer="yes"
AC_ARG_ENABLE(clang-static-analyzer,
@ -758,7 +786,6 @@ else
PowerPC) AC_SUBST(TARGET_HAS_JIT,1) ;;
x86_64) AC_SUBST(TARGET_HAS_JIT,1) ;;
ARM) AC_SUBST(TARGET_HAS_JIT,1) ;;
AArch64) AC_SUBST(TARGET_HAS_JIT,0) ;;
Mips) AC_SUBST(TARGET_HAS_JIT,1) ;;
XCore) AC_SUBST(TARGET_HAS_JIT,0) ;;
MSP430) AC_SUBST(TARGET_HAS_JIT,0) ;;
@ -769,7 +796,7 @@ else
esac
fi
TARGETS_WITH_JIT="AArch64 ARM Mips PowerPC SystemZ X86"
TARGETS_WITH_JIT="ARM AArch64 Mips PowerPC SystemZ X86"
AC_SUBST(TARGETS_WITH_JIT,$TARGETS_WITH_JIT)
dnl Allow enablement of building and installing docs
@ -922,14 +949,14 @@ if test "$llvm_cv_enable_crash_overrides" = "yes" ; then
fi
dnl List all possible targets
ALL_TARGETS="X86 Sparc PowerPC AArch64 ARM Mips XCore MSP430 CppBackend NVPTX Hexagon SystemZ R600"
ALL_TARGETS="X86 Sparc PowerPC ARM AArch64 Mips XCore MSP430 CppBackend NVPTX Hexagon SystemZ R600"
AC_SUBST(ALL_TARGETS,$ALL_TARGETS)
dnl Allow specific targets to be specified for building (or not)
TARGETS_TO_BUILD=""
AC_ARG_ENABLE([targets],AS_HELP_STRING([--enable-targets],
[Build specific host targets: all or target1,target2,... Valid targets are:
host, x86, x86_64, sparc, powerpc, arm, aarch64, mips, hexagon,
host, x86, x86_64, sparc, powerpc, arm64, arm, aarch64, mips, hexagon,
xcore, msp430, nvptx, systemz, r600, and cpp (default=all)]),,
enableval=all)
if test "$enableval" = host-only ; then
@ -944,6 +971,7 @@ case "$enableval" in
sparc) TARGETS_TO_BUILD="Sparc $TARGETS_TO_BUILD" ;;
powerpc) TARGETS_TO_BUILD="PowerPC $TARGETS_TO_BUILD" ;;
aarch64) TARGETS_TO_BUILD="AArch64 $TARGETS_TO_BUILD" ;;
arm64) TARGETS_TO_BUILD="AArch64 $TARGETS_TO_BUILD" ;;
arm) TARGETS_TO_BUILD="ARM $TARGETS_TO_BUILD" ;;
mips) TARGETS_TO_BUILD="Mips $TARGETS_TO_BUILD" ;;
mipsel) TARGETS_TO_BUILD="Mips $TARGETS_TO_BUILD" ;;

2
external/bsd/llvm/dist/llvm/autoconf/m4/link_options.m4 vendored
View File

@ -6,7 +6,7 @@
AC_DEFUN([AC_LINK_GET_VERSION],
[AC_CACHE_CHECK([for linker version],[llvm_cv_link_version],
[
version_string="$(ld -v 2>&1 | head -1)"
version_string="$(${LD:-ld} -v 2>&1 | head -1)"
# Check for ld64.
if (echo "$version_string" | grep -q "ld64"); then

2
external/bsd/llvm/dist/llvm/bindings/ocaml/Makefile vendored
View File

@ -9,7 +9,7 @@
LEVEL := ../..
DIRS = llvm bitreader bitwriter irreader analysis target executionengine \
transforms linker backends
transforms linker backends all_backends
ExtraMakefiles = $(PROJ_OBJ_DIR)/Makefile.ocaml
ocamldoc:

21
external/bsd/llvm/dist/llvm/bindings/ocaml/all_backends/Makefile vendored Normal file
View File

@ -0,0 +1,21 @@
##===- bindings/ocaml/all_backends/Makefile ----------------------*- Makefile -*-===##
#
# The LLVM Compiler Infrastructure
#
# This file is distributed under the University of Illinois Open Source
# License. See LICENSE.TXT for details.
#
##===----------------------------------------------------------------------===##
#
# This is the makefile for the Objective Caml Llvm_backends interface.
#
##===----------------------------------------------------------------------===##
LEVEL := ../../..
include $(LEVEL)/Makefile.config
LIBRARYNAME := llvm_all_backends
UsedComponents := $(TARGETS_TO_BUILD)
UsedOcamlInterfaces :=
include ../Makefile.ocaml

32
external/bsd/llvm/dist/llvm/bindings/ocaml/all_backends/all_backends_ocaml.c vendored Normal file
View File

@ -0,0 +1,32 @@
/*===-- all_backends_ocaml.c - LLVM OCaml Glue ------------------*- C++ -*-===*\
|* *|
|* The LLVM Compiler Infrastructure *|
|* *|
|* This file is distributed under the University of Illinois Open Source *|
|* License. See LICENSE.TXT for details. *|
|* *|
|*===----------------------------------------------------------------------===*|
|* *|
|* This file glues LLVM's OCaml interface to its C interface. These functions *|
|* are by and large transparent wrappers to the corresponding C functions. *|
|* *|
|* Note that these functions intentionally take liberties with the CAMLparamX *|
|* macros, since most of the parameters are not GC heap objects. *|
|* *|
\*===----------------------------------------------------------------------===*/
#include "llvm-c/Target.h"
#include "caml/alloc.h"
#include "caml/fail.h"
#include "caml/memory.h"
#include "caml/custom.h"
/* unit -> unit */
CAMLprim value llvm_initialize_all(value Unit) {
LLVMInitializeAllTargetInfos();
LLVMInitializeAllTargets();
LLVMInitializeAllTargetMCs();
LLVMInitializeAllAsmPrinters();
LLVMInitializeAllAsmParsers();
return Val_unit;
}

10
external/bsd/llvm/dist/llvm/bindings/ocaml/all_backends/llvm_all_backends.ml vendored Normal file
View File

@ -0,0 +1,10 @@
(*===-- llvm_all_backends.ml - LLVM OCaml Interface -----------*- OCaml -*-===*
*
* The LLVM Compiler Infrastructure
*
* This file is distributed under the University of Illinois Open Source
* License. See LICENSE.TXT for details.
*
*===----------------------------------------------------------------------===*)
external initialize : unit -> unit = "llvm_initialize_all"

11
external/bsd/llvm/dist/llvm/bindings/ocaml/all_backends/llvm_all_backends.mli vendored Normal file
View File

@ -0,0 +1,11 @@
(*===-- llvm_all_backends.mli - LLVM OCaml Interface ----------*- OCaml -*-===*
*
* The LLVM Compiler Infrastructure
*
* This file is distributed under the University of Illinois Open Source
* License. See LICENSE.TXT for details.
*
*===----------------------------------------------------------------------===*)
(** Initialize all the backends targets *)
val initialize : unit -> unit

8
external/bsd/llvm/dist/llvm/bindings/ocaml/llvm/META.llvm.in vendored
View File

@ -93,3 +93,11 @@ package "linker" (
archive(byte) = "llvm_linker.cma"
archive(native) = "llvm_linker.cmxa"
)
package "all_backends" (
requires = "llvm"
version = "@PACKAGE_VERSION@"
description = "All backends for LLVM"
archive(byte) = "llvm_all_backends.cma"
archive(native) = "llvm_all_backends.cmxa"
)

25
external/bsd/llvm/dist/llvm/bindings/python/llvm/object.py vendored
View File

@ -78,7 +78,10 @@ Here are some examples on how to perform iteration:
"""
from ctypes import c_char_p
from ctypes import c_char
from ctypes import POINTER
from ctypes import c_uint64
from ctypes import string_at
from .common import CachedProperty
from .common import LLVMObject
@ -211,7 +214,12 @@ class Section(LLVMObject):
if self.expired:
raise Exception('Section instance has expired.')
return lib.LLVMGetSectionContents(self)
siz = self.size
r = lib.LLVMGetSectionContents(self)
if r:
return string_at(r, siz)
return None
@CachedProperty
def address(self):
@ -310,14 +318,6 @@ class Symbol(LLVMObject):
return lib.LLVMGetSymbolAddress(self)
@CachedProperty
def file_offset(self):
"""The offset of this symbol in the file, in long bytes."""
if self.expired:
raise Exception('Symbol instance has expired.')
return lib.LLVMGetSymbolFileOffset(self)
@CachedProperty
def size(self):
"""The size of the symbol, in long bytes."""
@ -345,7 +345,6 @@ class Symbol(LLVMObject):
"""Cache all cacheable properties."""
getattr(self, 'name')
getattr(self, 'address')
getattr(self, 'file_offset')
getattr(self, 'size')
def expire(self):
@ -471,7 +470,8 @@ def register_library(library):
library.LLVMGetSectionSize.restype = c_uint64
library.LLVMGetSectionContents.argtypes = [c_object_p]
library.LLVMGetSectionContents.restype = c_char_p
# Can't use c_char_p here as it isn't a NUL-terminated string.
library.LLVMGetSectionContents.restype = POINTER(c_char)
library.LLVMGetSectionAddress.argtypes = [c_object_p]
library.LLVMGetSectionAddress.restype = c_uint64
@ -495,9 +495,6 @@ def register_library(library):
library.LLVMGetSymbolAddress.argtypes = [Symbol]
library.LLVMGetSymbolAddress.restype = c_uint64
library.LLVMGetSymbolFileOffset.argtypes = [Symbol]
library.LLVMGetSymbolFileOffset.restype = c_uint64
library.LLVMGetSymbolSize.argtypes = [Symbol]
library.LLVMGetSymbolSize.restype = c_uint64

2
external/bsd/llvm/dist/llvm/bindings/python/llvm/tests/test_object.py vendored
View File

@ -23,6 +23,7 @@ class TestObjectFile(TestBase):
assert isinstance(section.size, long)
assert isinstance(section.contents, str)
assert isinstance(section.address, long)
assert len(section.contents) == section.size
self.assertGreater(count, 0)
@ -39,7 +40,6 @@ class TestObjectFile(TestBase):
assert isinstance(symbol.name, str)
assert isinstance(symbol.address, long)
assert isinstance(symbol.size, long)
assert isinstance(symbol.file_offset, long)
self.assertGreater(count, 0)

19
external/bsd/llvm/dist/llvm/cmake/config-ix.cmake vendored
View File

@ -17,6 +17,11 @@ if( UNIX AND NOT BEOS )
# Used by check_symbol_exists:
set(CMAKE_REQUIRED_LIBRARIES m)
endif()
# x86_64 FreeBSD 9.2 requires libcxxrt to be specified explicitly.
if( CMAKE_SYSTEM MATCHES "FreeBSD-9.2-RELEASE" AND
CMAKE_SIZEOF_VOID_P EQUAL 8 )
list(APPEND CMAKE_REQUIRED_LIBRARIES "cxxrt")
endif()
# Helper macros and functions
macro(add_cxx_include result files)
@ -366,6 +371,8 @@ elseif (LLVM_NATIVE_ARCH MATCHES "powerpc")
set(LLVM_NATIVE_ARCH PowerPC)
elseif (LLVM_NATIVE_ARCH MATCHES "aarch64")
set(LLVM_NATIVE_ARCH AArch64)
elseif (LLVM_NATIVE_ARCH MATCHES "arm64")
set(LLVM_NATIVE_ARCH AArch64)
elseif (LLVM_NATIVE_ARCH MATCHES "arm")
set(LLVM_NATIVE_ARCH ARM)
elseif (LLVM_NATIVE_ARCH MATCHES "mips")
@ -479,7 +486,7 @@ set(LLVM_PREFIX ${CMAKE_INSTALL_PREFIX})
if (LLVM_ENABLE_DOXYGEN)
message(STATUS "Doxygen enabled.")
find_package(Doxygen)
find_package(Doxygen REQUIRED)
if (DOXYGEN_FOUND)
# If we find doxygen and we want to enable doxygen by default create a
@ -498,3 +505,13 @@ if (LLVM_ENABLE_DOXYGEN)
else()
message(STATUS "Doxygen disabled.")
endif()
if (LLVM_ENABLE_SPHINX)
message(STATUS "Sphinx enabled.")
find_package(Sphinx REQUIRED)
if (LLVM_BUILD_DOCS)
add_custom_target(sphinx ALL)
endif()
else()
message(STATUS "Sphinx disabled.")
endif()

18
external/bsd/llvm/dist/llvm/cmake/modules/AddLLVM.cmake vendored
View File

@ -276,6 +276,11 @@ function(llvm_add_library name)
endif()
if(ARG_SHARED)
if(WIN32)
set_target_properties(${name} PROPERTIES
PREFIX ""
)
endif()
if (MSVC)
set_target_properties(${name}
PROPERTIES
@ -456,7 +461,7 @@ macro(add_llvm_target target_name)
include_directories(BEFORE
${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_CURRENT_SOURCE_DIR})
add_llvm_library(LLVM${target_name} ${ARGN} ${TABLEGEN_OUTPUT})
add_llvm_library(LLVM${target_name} ${ARGN})
set( CURRENT_LLVM_TARGET LLVM${target_name} )
endmacro(add_llvm_target)
@ -627,11 +632,12 @@ function(add_lit_target target comment)
if (NOT CMAKE_CFG_INTDIR STREQUAL ".")
list(APPEND LIT_ARGS --param build_mode=${CMAKE_CFG_INTDIR})
endif ()
set(LIT_COMMAND
${PYTHON_EXECUTABLE}
${LLVM_MAIN_SRC_DIR}/utils/lit/lit.py
${LIT_ARGS}
)
if (LLVM_MAIN_SRC_DIR)
set (LIT_COMMAND ${PYTHON_EXECUTABLE} ${LLVM_MAIN_SRC_DIR}/utils/lit/lit.py)
else()
find_program(LIT_COMMAND llvm-lit)
endif ()
list(APPEND LIT_COMMAND ${LIT_ARGS})
foreach(param ${ARG_PARAMS})
list(APPEND LIT_COMMAND --param ${param})
endforeach()

56
external/bsd/llvm/dist/llvm/cmake/modules/AddSphinxTarget.cmake vendored Normal file
View File

@ -0,0 +1,56 @@
# Handy function for creating the different Sphinx targets.
#
# ``builder`` should be one of the supported builders used by
# the sphinx-build command.
#
# ``project`` should be the project name
function (add_sphinx_target builder project)
set(SPHINX_BUILD_DIR "${CMAKE_CURRENT_BINARY_DIR}/${builder}")
set(SPHINX_DOC_TREE_DIR "${CMAKE_CURRENT_BINARY_DIR}/_doctrees")
set(SPHINX_TARGET_NAME docs-${project}-${builder})
add_custom_target(${SPHINX_TARGET_NAME}
COMMAND ${SPHINX_EXECUTABLE}
-b ${builder}
-d "${SPHINX_DOC_TREE_DIR}"
-q # Quiet: no output other than errors and warnings.
-W # Warnings are errors.
"${CMAKE_CURRENT_SOURCE_DIR}" # Source
"${SPHINX_BUILD_DIR}" # Output
COMMENT
"Generating ${builder} Sphinx documentation for ${project}")
# When "clean" target is run, remove the Sphinx build directory
set_property(DIRECTORY APPEND PROPERTY
ADDITIONAL_MAKE_CLEAN_FILES
"${SPHINX_BUILD_DIR}")
# We need to remove ${SPHINX_DOC_TREE_DIR} when make clean is run
# but we should only add this path once
get_property(_CURRENT_MAKE_CLEAN_FILES
DIRECTORY PROPERTY ADDITIONAL_MAKE_CLEAN_FILES)
list(FIND _CURRENT_MAKE_CLEAN_FILES "${SPHINX_DOC_TREE_DIR}" _INDEX)
if (_INDEX EQUAL -1)
set_property(DIRECTORY APPEND PROPERTY
ADDITIONAL_MAKE_CLEAN_FILES
"${SPHINX_DOC_TREE_DIR}")
endif()
if (LLVM_BUILD_DOCS)
add_dependencies(sphinx ${SPHINX_TARGET_NAME})
# Handle installation
if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
if (builder STREQUAL man)
# FIXME: We might not ship all the tools that these man pages describe
install(DIRECTORY "${SPHINX_BUILD_DIR}/" # Slash indicates contents of
DESTINATION share/man/man1)
elseif (builder STREQUAL html)
install(DIRECTORY "${SPHINX_BUILD_DIR}"
DESTINATION "share/doc/${project}")
else()
message(WARNING Installation of ${builder} not supported)
endif()
endif()
endif()
endfunction()

25
external/bsd/llvm/dist/llvm/cmake/modules/FindSphinx.cmake vendored Normal file
View File

@ -0,0 +1,25 @@
# CMake find_package() Module for Sphinx documentation generator
# http://sphinx-doc.org/
#
# Example usage:
#
# find_package(Sphinx)
#
# If successful the following variables will be defined
# SPHINX_FOUND
# SPHINX_EXECUTABLE
find_program(SPHINX_EXECUTABLE
NAMES sphinx-build sphinx-build2
DOC "Path to sphinx-build executable")
# Handle REQUIRED and QUIET arguments
# this will also set SPHINX_FOUND to true if SPHINX_EXECUTABLE exists
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(Sphinx
"Failed to locate sphinx-build executable"
SPHINX_EXECUTABLE)
# Provide options for controlling different types of output
option(SPHINX_OUTPUT_HTML "Output standalone HTML files" ON)
option(SPHINX_OUTPUT_MAN "Output man pages" ON)

104
external/bsd/llvm/dist/llvm/cmake/modules/HandleLLVMOptions.cmake vendored
View File

@ -56,13 +56,16 @@ if( LLVM_ENABLE_ASSERTIONS )
if( NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" )
add_definitions( -UNDEBUG )
# Also remove /D NDEBUG to avoid MSVC warnings about conflicting defines.
set(REGEXP_NDEBUG "(^| )[/-]D *NDEBUG($| )")
string (REGEX REPLACE "${REGEXP_NDEBUG}" " "
CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE}")
string (REGEX REPLACE "${REGEXP_NDEBUG}" " "
CMAKE_CXX_FLAGS_RELWITHDEBINFO "${CMAKE_CXX_FLAGS_RELWITHDEBINFO}")
string (REGEX REPLACE "${REGEXP_NDEBUG}" " "
CMAKE_CXX_FLAGS_MINSIZEREL "${CMAKE_CXX_FLAGS_MINSIZEREL}")
foreach (flags_var_to_scrub
CMAKE_CXX_FLAGS_RELEASE
CMAKE_CXX_FLAGS_RELWITHDEBINFO
CMAKE_CXX_FLAGS_MINSIZEREL
CMAKE_C_FLAGS_RELEASE
CMAKE_C_FLAGS_RELWITHDEBINFO
CMAKE_C_FLAGS_MINSIZEREL)
string (REGEX REPLACE "(^| )[/-]D *NDEBUG($| )" " "
"${flags_var_to_scrub}" "${${flags_var_to_scrub}}")
endforeach()
endif()
else()
if( NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "RELEASE" )
@ -173,6 +176,29 @@ if( CMAKE_SIZEOF_VOID_P EQUAL 8 AND NOT WIN32 )
endif( LLVM_BUILD_32_BITS )
endif( CMAKE_SIZEOF_VOID_P EQUAL 8 AND NOT WIN32 )
if( XCODE )
# For Xcode enable several build settings that correspond to
# many warnings that are on by default in Clang but are
# not enabled for historical reasons. For versions of Xcode
# that do not support these options they will simply
# be ignored.
set(CMAKE_XCODE_ATTRIBUTE_GCC_WARN_ABOUT_RETURN_TYPE "YES")
set(CMAKE_XCODE_ATTRIBUTE_GCC_WARN_ABOUT_MISSING_NEWLINE "YES")
set(CMAKE_XCODE_ATTRIBUTE_GCC_WARN_UNUSED_VALUE "YES")
set(CMAKE_XCODE_ATTRIBUTE_GCC_WARN_UNUSED_VARIABLE "YES")
set(CMAKE_XCODE_ATTRIBUTE_GCC_WARN_SIGN_COMPARE "YES")
set(CMAKE_XCODE_ATTRIBUTE_GCC_WARN_UNUSED_FUNCTION "YES")
set(CMAKE_XCODE_ATTRIBUTE_GCC_WARN_INITIALIZER_NOT_FULLY_BRACKETED "YES")
set(CMAKE_XCODE_ATTRIBUTE_GCC_WARN_HIDDEN_VIRTUAL_FUNCTIONS "YES")
set(CMAKE_XCODE_ATTRIBUTE_GCC_WARN_UNINITIALIZED_AUTOS "YES")
set(CMAKE_XCODE_ATTRIBUTE_CLANG_WARN_BOOL_CONVERSION "YES")
set(CMAKE_XCODE_ATTRIBUTE_CLANG_WARN_EMPTY_BODY "YES")
set(CMAKE_XCODE_ATTRIBUTE_CLANG_WARN_ENUM_CONVERSION "YES")
set(CMAKE_XCODE_ATTRIBUTE_CLANG_WARN_INT_CONVERSION "YES")
set(CMAKE_XCODE_ATTRIBUTE_CLANG_WARN_CONSTANT_CONVERSION "YES")
set(CMAKE_XCODE_ATTRIBUTE_GCC_WARN_NON_VIRTUAL_DESTRUCTOR "YES")
endif()
# On Win32 using MS tools, provide an option to set the number of parallel jobs
# to use.
if( MSVC_IDE )
@ -182,14 +208,8 @@ if( MSVC_IDE )
if( LLVM_COMPILER_JOBS STREQUAL "0" )
add_llvm_definitions( /MP )
else()
if (MSVC10)
message(FATAL_ERROR
"Due to a bug in CMake only 0 and 1 is supported for "
"LLVM_COMPILER_JOBS when generating for Visual Studio 2010")
else()
message(STATUS "Number of parallel compiler jobs set to " ${LLVM_COMPILER_JOBS})
add_llvm_definitions( /MP${LLVM_COMPILER_JOBS} )
endif()
message(STATUS "Number of parallel compiler jobs set to " ${LLVM_COMPILER_JOBS})
add_llvm_definitions( /MP${LLVM_COMPILER_JOBS} )
endif()
else()
message(STATUS "Parallel compilation disabled")
@ -208,13 +228,7 @@ if( MSVC )
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /STACK:10000000")
endif()
if( MSVC10 )
# MSVC 10 will complain about headers in the STL not being exported, but
# will not complain in MSVC 11.
add_llvm_definitions(
-wd4275 # Suppress 'An exported class was derived from a class that was not exported.'
)
elseif( MSVC11 )
if( MSVC11 )
add_llvm_definitions(-D_VARIADIC_MAX=10)
endif()
@ -233,13 +247,14 @@ if( MSVC )
-wd4180 # Suppress 'qualifier applied to function type has no meaning; ignored'
-wd4244 # Suppress ''argument' : conversion from 'type1' to 'type2', possible loss of data'
-wd4267 # Suppress ''var' : conversion from 'size_t' to 'type', possible loss of data'
-wd4291 # Suppress ''declaration' : no matching operator delete found; memory will not be freed if initialization throws an exception'
-wd4345 # Suppress 'behavior change: an object of POD type constructed with an initializer of the form () will be default-initialized'
-wd4351 # Suppress 'new behavior: elements of array 'array' will be default initialized'
-wd4355 # Suppress ''this' : used in base member initializer list'
-wd4503 # Suppress ''identifier' : decorated name length exceeded, name was truncated'
-wd4624 # Suppress ''derived class' : destructor could not be generated because a base class destructor is inaccessible'
-wd4722 # Suppress 'function' : destructor never returns, potential memory leak
-wd4800 # Suppress ''type' : forcing value to bool 'true' or 'false' (performance warning)'
-wd4291 # Suppress ''declaration' : no matching operator delete found; memory will not be freed if initialization throws an exception'
# Promoted warnings.
-w14062 # Promote 'enumerator in switch of enum is not handled' to level 1 warning.
@ -283,14 +298,36 @@ elseif( LLVM_COMPILER_IS_GCC_COMPATIBLE )
append_if(USE_NO_MAYBE_UNINITIALIZED "-Wno-maybe-uninitialized" CMAKE_CXX_FLAGS)
check_cxx_compiler_flag("-Werror -Wnon-virtual-dtor" CXX_SUPPORTS_NON_VIRTUAL_DTOR_FLAG)
append_if(CXX_SUPPORTS_NON_VIRTUAL_DTOR_FLAG "-Wnon-virtual-dtor" CMAKE_CXX_FLAGS)
# Check if -Wcomment is OK with an // comment ending with '\' if the next
# line is also a // comment.
set(OLD_CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS})
set(CMAKE_REQUIRED_FLAGS ${CMAKE_REQUIRED_FLAGS} -Werror -Wcomment)
CHECK_C_SOURCE_COMPILES("// \\\\\\n//\\nint main() {return 0;}"
C_WCOMMENT_ALLOWS_LINE_WRAP)
set(CMAKE_REQUIRED_FLAGS ${OLD_CMAKE_REQUIRED_FLAGS})
if (NOT C_WCOMMENT_ALLOWS_LINE_WRAP)
append("-Wno-comment" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
endif()
endif (LLVM_ENABLE_WARNINGS)
if (LLVM_ENABLE_WERROR)
add_llvm_definitions( -Werror )
endif (LLVM_ENABLE_WERROR)
if (LLVM_ENABLE_CXX11)
append_if(LLVM_ENABLE_WERROR "-Werror" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)
if (LLVM_ENABLE_CXX1Y)
check_cxx_compiler_flag("-std=c++1y" CXX_SUPPORTS_CXX1Y)
append_if(CXX_SUPPORTS_CXX1Y "-std=c++1y" CMAKE_CXX_FLAGS)
else()
check_cxx_compiler_flag("-std=c++11" CXX_SUPPORTS_CXX11)
append_if(CXX_SUPPORTS_CXX11 "-std=c++11" CMAKE_CXX_FLAGS)
endif (LLVM_ENABLE_CXX11)
if (CXX_SUPPORTS_CXX11)
if (CYGWIN OR MINGW)
# MinGW and Cygwin are a bit stricter and lack things like
# 'strdup', 'stricmp', etc in c++11 mode.
append("-std=gnu++11" CMAKE_CXX_FLAGS)
else()
append("-std=c++11" CMAKE_CXX_FLAGS)
endif()
else()
message(FATAL_ERROR "LLVM requires C++11 support but the '-std=c++11' flag isn't supported.")
endif()
endif()
endif( MSVC )
macro(append_common_sanitizer_flags)
@ -365,6 +402,15 @@ if(NOT CYGWIN AND NOT WIN32)
endif()
endif()
if(CYGWIN OR MINGW)
# Prune --out-implib from executables. It doesn't make sense even
# with --export-all-symbols.
string(REGEX REPLACE "-Wl,--out-implib,[^ ]+ " " "
CMAKE_C_LINK_EXECUTABLE "${CMAKE_C_LINK_EXECUTABLE}")
string(REGEX REPLACE "-Wl,--out-implib,[^ ]+ " " "
CMAKE_CXX_LINK_EXECUTABLE "${CMAKE_CXX_LINK_EXECUTABLE}")
endif()
if(MSVC)
# Remove flags here, for exceptions and RTTI.
# Each target property or source property should be responsible to control

1
external/bsd/llvm/dist/llvm/cmake/modules/LLVMConfig.cmake.in vendored
View File

@ -4,6 +4,7 @@
set(LLVM_VERSION_MAJOR @LLVM_VERSION_MAJOR@)
set(LLVM_VERSION_MINOR @LLVM_VERSION_MINOR@)
set(LLVM_VERSION_PATCH @LLVM_VERSION_PATCH@)
set(LLVM_PACKAGE_VERSION @PACKAGE_VERSION@)
set(LLVM_COMMON_DEPENDS @LLVM_COMMON_DEPENDS@)

14
external/bsd/llvm/dist/llvm/cmake/modules/LLVMConfigVersion.cmake.in vendored
View File

@ -1 +1,13 @@
set(PACKAGE_VERSION "@PACKAGE_VERSION@")
set(PACKAGE_VERSION "@PACKAGE_VERSION@")
# LLVM is API-compatible only with matching major.minor versions
# and patch versions not less than that requested.
if("@LLVM_VERSION_MAJOR@.@LLVM_VERSION_MINOR@" VERSION_EQUAL
"${PACKAGE_FIND_VERSION_MAJOR}.${PACKAGE_FIND_VERSION_MINOR}"
AND NOT "@LLVM_VERSION_PATCH@" VERSION_LESS "${PACKAGE_FIND_VERSION_PATCH}")
set(PACKAGE_VERSION_COMPATIBLE 1)
if("@LLVM_VERSION_PATCH@" VERSION_EQUAL
"${PACKAGE_FIND_VERSION_PATCH}")
set(PACKAGE_VERSION_EXACT 1)
endif()
endif()

4
external/bsd/llvm/dist/llvm/cmake/modules/Makefile vendored
View File

@ -24,6 +24,7 @@ $(PROJ_OBJ_DIR)/LLVMConfig.cmake: LLVMConfig.cmake.in $(LLVMBuildCMakeFrag)
-e 's/@LLVM_CONFIG_CODE@/set(LLVM_INSTALL_PREFIX "'"$(subst /,\/,$(PROJ_prefix))"'")/' \
-e 's/@LLVM_VERSION_MAJOR@/'"$(LLVM_VERSION_MAJOR)"'/' \
-e 's/@LLVM_VERSION_MINOR@/'"$(LLVM_VERSION_MINOR)"'/' \
-e 's/@LLVM_VERSION_PATCH@/'"$(LLVM_VERSION_PATCH)"'/' \
-e 's/@PACKAGE_VERSION@/'"$(LLVMVersion)"'/' \
-e 's/@LLVM_COMMON_DEPENDS@//' \
-e 's/@LLVM_AVAILABLE_LIBS@/'"$(subst -l,,$(LLVMConfigLibs))"'/' \
@ -51,6 +52,9 @@ $(PROJ_OBJ_DIR)/LLVMConfigVersion.cmake: LLVMConfigVersion.cmake.in
$(Echo) 'Generating LLVM CMake package version file'
$(Verb) cat $< | sed \
-e 's/@PACKAGE_VERSION@/'"$(LLVMVersion)"'/' \
-e 's/@LLVM_VERSION_MAJOR@/'"$(LLVM_VERSION_MAJOR)"'/' \
-e 's/@LLVM_VERSION_MINOR@/'"$(LLVM_VERSION_MINOR)"'/' \
-e 's/@LLVM_VERSION_PATCH@/'"$(LLVM_VERSION_PATCH)"'/' \
> $@
$(PROJ_OBJ_DIR)/LLVMExports.cmake: $(LLVMBuildCMakeExportsFrag)

BIN
external/bsd/llvm/dist/llvm/cmake/nsis_icon.ico vendored Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 64 KiB

128
external/bsd/llvm/dist/llvm/configure vendored
View File

@ -1,6 +1,6 @@
#! /bin/sh
# Guess values for system-dependent variables and create Makefiles.
# Generated by GNU Autoconf 2.60 for LLVM 3.5svn.
# Generated by GNU Autoconf 2.60 for LLVM 3.5.0svn.
#
# Report bugs to <http://llvm.org/bugs/>.
#
@ -561,8 +561,8 @@ SHELL=${CONFIG_SHELL-/bin/sh}
# Identity of this package.
PACKAGE_NAME='LLVM'
PACKAGE_TARNAME='llvm'
PACKAGE_VERSION='3.5svn'
PACKAGE_STRING='LLVM 3.5svn'
PACKAGE_VERSION='3.5.0svn'
PACKAGE_STRING='LLVM 3.5.0svn'
PACKAGE_BUGREPORT='http://llvm.org/bugs/'
ac_unique_file="lib/IR/Module.cpp"
@ -641,6 +641,8 @@ host_alias
target_alias
LLVM_VERSION_MAJOR
LLVM_VERSION_MINOR
LLVM_VERSION_PATCH
LLVM_VERSION_SUFFIX
LLVM_COPYRIGHT
CC
CFLAGS
@ -684,9 +686,10 @@ BUILD_EXEEXT
BUILD_CXX
CVSBUILD
ENABLE_LIBCPP
ENABLE_CXX11
ENABLE_CXX1Y
ENABLE_SPLIT_DWARF
ENABLE_CLANG_ARCMT
CLANG_PLUGIN_SUPPORT
ENABLE_CLANG_STATIC_ANALYZER
ENABLE_CLANG_REWRITER
ENABLE_OPTIMIZED
@ -820,7 +823,6 @@ ac_subdirs_all='projects/test-suite
projects/llvm-test
projects/poolalloc
projects/llvm-poolalloc
projects/sample
projects/safecode
tools/polly'
@ -1324,7 +1326,7 @@ if test "$ac_init_help" = "long"; then
# Omit some internal or obsolete options to make the list less imposing.
# This message is too long to be a string in the A/UX 3.1 sh.
cat <<_ACEOF
\`configure' configures LLVM 3.5svn to adapt to many kinds of systems.
\`configure' configures LLVM 3.5.0svn to adapt to many kinds of systems.
Usage: $0 [OPTION]... [VAR=VALUE]...
@ -1390,7 +1392,7 @@ fi
if test -n "$ac_init_help"; then
case $ac_init_help in
short | recursive ) echo "Configuration of LLVM 3.5svn:";;
short | recursive ) echo "Configuration of LLVM 3.5.0svn:";;
esac
cat <<\_ACEOF
@ -1402,9 +1404,11 @@ Optional Features:
--enable-compiler-version-checks
Check the version of the host compiler (default is
YES)
--enable-cxx11 Use c++11 if available (default is YES)
--enable-cxx1y Use c++1y if available (default is NO)
--enable-split-dwarf Use split-dwarf if available (default is NO)
--enable-clang-arcmt Enable building of clang ARCMT (default is YES)
--enable-clang-plugin-support
Enable plugin support in clang (default is YES)
--enable-clang-static-analyzer
Enable building of clang Static Analyzer (default is
YES)
@ -1443,9 +1447,9 @@ Optional Features:
Enable crash handling overrides (default is YES)
--enable-targets Build specific host targets: all or
target1,target2,... Valid targets are: host, x86,
x86_64, sparc, powerpc, arm, aarch64, mips, hexagon,
xcore, msp430, nvptx, systemz, r600, and cpp
(default=all)
x86_64, sparc, powerpc, arm64, arm, aarch64, mips,
hexagon, xcore, msp430, nvptx, systemz, r600, and
cpp (default=all)
--enable-experimental-targets
Build experimental host targets: disable or
target1,target2,... (default=disable)
@ -1561,7 +1565,7 @@ fi
test -n "$ac_init_help" && exit $ac_status
if $ac_init_version; then
cat <<\_ACEOF
LLVM configure 3.5svn
LLVM configure 3.5.0svn
generated by GNU Autoconf 2.60
Copyright (C) 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001,
@ -1577,7 +1581,7 @@ cat >config.log <<_ACEOF
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by LLVM $as_me 3.5svn, which was
It was created by LLVM $as_me 3.5.0svn, which was
generated by GNU Autoconf 2.60. Invocation command line was
$ $0 $@
@ -1931,21 +1935,29 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
LLVM_VERSION_MAJOR=3
LLVM_VERSION_MINOR=5
LLVM_VERSION_PATCH=0
LLVM_VERSION_SUFFIX=svn
cat >>confdefs.h <<\_ACEOF
#define LLVM_VERSION_MAJOR 3
cat >>confdefs.h <<_ACEOF
#define LLVM_VERSION_MAJOR $LLVM_VERSION_MAJOR
_ACEOF
LLVM_VERSION_MAJOR='3'
cat >>confdefs.h <<\_ACEOF
#define LLVM_VERSION_MINOR 5
cat >>confdefs.h <<_ACEOF
#define LLVM_VERSION_MINOR $LLVM_VERSION_MINOR
_ACEOF
LLVM_VERSION_MINOR='5'
cat >>confdefs.h <<_ACEOF
#define LLVM_VERSION_PATCH $LLVM_VERSION_PATCH
_ACEOF
@ -3738,8 +3750,6 @@ for i in `ls ${srcdir}/projects`
do
if test -d ${srcdir}/projects/${i} ; then
case ${i} in
sample) subdirs="$subdirs projects/sample"
;;
safecode) subdirs="$subdirs projects/safecode"
;;
compiler-rt) ;;
@ -4141,6 +4151,7 @@ else
amd64-* | x86_64-*) llvm_cv_target_arch="x86_64" ;;
sparc*-*) llvm_cv_target_arch="Sparc" ;;
powerpc*-*) llvm_cv_target_arch="PowerPC" ;;
arm64*-*) llvm_cv_target_arch="AArch64" ;;
arm*-*) llvm_cv_target_arch="ARM" ;;
aarch64*-*) llvm_cv_target_arch="AArch64" ;;
mips-* | mips64-*) llvm_cv_target_arch="Mips" ;;
@ -4177,6 +4188,7 @@ case $host in
amd64-* | x86_64-*) host_arch="x86_64" ;;
sparc*-*) host_arch="Sparc" ;;
powerpc*-*) host_arch="PowerPC" ;;
arm64*-*) host_arch="AArch64" ;;
arm*-*) host_arch="ARM" ;;
aarch64*-*) host_arch="AArch64" ;;
mips-* | mips64-*) host_arch="Mips" ;;
@ -4804,22 +4816,22 @@ echo "$as_me: error: Invalid setting for --enable-compiler-version-checks. Use \
;;
esac
# Check whether --enable-cxx11 was given.
if test "${enable_cxx11+set}" = set; then
enableval=$enable_cxx11;
# Check whether --enable-cxx1y was given.
if test "${enable_cxx1y+set}" = set; then
enableval=$enable_cxx1y;
else
enableval=default
fi
case "$enableval" in
yes) ENABLE_CXX11=1
yes) ENABLE_CXX1Y=1
;;
no) ENABLE_CXX11=0
no) ENABLE_CXX1Y=0
;;
default) ENABLE_CXX11=1
default) ENABLE_CXX1Y=0
;;
*) { { echo "$as_me:$LINENO: error: Invalid setting for --enable-cxx11. Use \"yes\" or \"no\"" >&5
echo "$as_me: error: Invalid setting for --enable-cxx11. Use \"yes\" or \"no\"" >&2;}
*) { { echo "$as_me:$LINENO: error: Invalid setting for --enable-cxx1y. Use \"yes\" or \"no\"" >&5
echo "$as_me: error: Invalid setting for --enable-cxx1y. Use \"yes\" or \"no\"" >&2;}
{ (exit 1); exit 1; }; } ;;
esac
@ -4862,6 +4874,26 @@ echo "$as_me: error: Invalid setting for --enable-clang-arcmt. Use \"yes\" or \"
{ (exit 1); exit 1; }; } ;;
esac
clang_plugin_support="yes"
# Check whether --enable-clang-plugin-support was given.
if test "${enable_clang_plugin_support+set}" = set; then
enableval=$enable_clang_plugin_support; clang_plugin_support="$enableval"
else
enableval="yes"
fi
case "$enableval" in
yes) CLANG_PLUGIN_SUPPORT=1
;;
no) CLANG_PLUGIN_SUPPORT=0
;;
default) CLANG_PLUGIN_SUPPORT=1
;;
*) { { echo "$as_me:$LINENO: error: Invalid setting for --enable-clang-plugin-support. Use \"yes\" or \"no\"" >&5
echo "$as_me: error: Invalid setting for --enable-clang-plugin-support. Use \"yes\" or \"no\"" >&2;}
{ (exit 1); exit 1; }; } ;;
esac
clang_static_analyzer="yes"
# Check whether --enable-clang-static-analyzer was given.
if test "${enable_clang_static_analyzer+set}" = set; then
@ -5070,8 +5102,6 @@ else
x86_64) TARGET_HAS_JIT=1
;;
ARM) TARGET_HAS_JIT=1
;;
AArch64) TARGET_HAS_JIT=0
;;
Mips) TARGET_HAS_JIT=1
;;
@ -5090,7 +5120,7 @@ else
esac
fi
TARGETS_WITH_JIT="AArch64 ARM Mips PowerPC SystemZ X86"
TARGETS_WITH_JIT="ARM AArch64 Mips PowerPC SystemZ X86"
TARGETS_WITH_JIT=$TARGETS_WITH_JIT
@ -5327,7 +5357,7 @@ _ACEOF
fi
ALL_TARGETS="X86 Sparc PowerPC AArch64 ARM Mips XCore MSP430 CppBackend NVPTX Hexagon SystemZ R600"
ALL_TARGETS="X86 Sparc PowerPC ARM AArch64 Mips XCore MSP430 CppBackend NVPTX Hexagon SystemZ R600"
ALL_TARGETS=$ALL_TARGETS
@ -5351,6 +5381,7 @@ case "$enableval" in
sparc) TARGETS_TO_BUILD="Sparc $TARGETS_TO_BUILD" ;;
powerpc) TARGETS_TO_BUILD="PowerPC $TARGETS_TO_BUILD" ;;
aarch64) TARGETS_TO_BUILD="AArch64 $TARGETS_TO_BUILD" ;;
arm64) TARGETS_TO_BUILD="AArch64 $TARGETS_TO_BUILD" ;;
arm) TARGETS_TO_BUILD="ARM $TARGETS_TO_BUILD" ;;
mips) TARGETS_TO_BUILD="Mips $TARGETS_TO_BUILD" ;;
mipsel) TARGETS_TO_BUILD="Mips $TARGETS_TO_BUILD" ;;
@ -7581,7 +7612,7 @@ if test "${llvm_cv_link_version+set}" = set; then
echo $ECHO_N "(cached) $ECHO_C" >&6
else
version_string="$(ld -v 2>&1 | head -1)"
version_string="$(${LD:-ld} -v 2>&1 | head -1)"
# Check for ld64.
if (echo "$version_string" | grep -q "ld64"); then
@ -19829,7 +19860,7 @@ exec 6>&1
# report actual input values of CONFIG_FILES etc. instead of their
# values after options handling.
ac_log="
This file was extended by LLVM $as_me 3.5svn, which was
This file was extended by LLVM $as_me 3.5.0svn, which was
generated by GNU Autoconf 2.60. Invocation command line was
CONFIG_FILES = $CONFIG_FILES
@ -19882,7 +19913,7 @@ Report bugs to <bug-autoconf@gnu.org>."
_ACEOF
cat >>$CONFIG_STATUS <<_ACEOF
ac_cs_version="\\
LLVM config.status 3.5svn
LLVM config.status 3.5.0svn
configured by $0, generated by GNU Autoconf 2.60,
with options \\"`echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/\\\\&/g'`\\"
@ -20122,6 +20153,8 @@ host_alias!$host_alias$ac_delim
target_alias!$target_alias$ac_delim
LLVM_VERSION_MAJOR!$LLVM_VERSION_MAJOR$ac_delim
LLVM_VERSION_MINOR!$LLVM_VERSION_MINOR$ac_delim
LLVM_VERSION_PATCH!$LLVM_VERSION_PATCH$ac_delim
LLVM_VERSION_SUFFIX!$LLVM_VERSION_SUFFIX$ac_delim
LLVM_COPYRIGHT!$LLVM_COPYRIGHT$ac_delim
CC!$CC$ac_delim
CFLAGS!$CFLAGS$ac_delim
@ -20165,9 +20198,10 @@ BUILD_EXEEXT!$BUILD_EXEEXT$ac_delim
BUILD_CXX!$BUILD_CXX$ac_delim
CVSBUILD!$CVSBUILD$ac_delim
ENABLE_LIBCPP!$ENABLE_LIBCPP$ac_delim
ENABLE_CXX11!$ENABLE_CXX11$ac_delim
ENABLE_CXX1Y!$ENABLE_CXX1Y$ac_delim
ENABLE_SPLIT_DWARF!$ENABLE_SPLIT_DWARF$ac_delim
ENABLE_CLANG_ARCMT!$ENABLE_CLANG_ARCMT$ac_delim
CLANG_PLUGIN_SUPPORT!$CLANG_PLUGIN_SUPPORT$ac_delim
ENABLE_CLANG_STATIC_ANALYZER!$ENABLE_CLANG_STATIC_ANALYZER$ac_delim
ENABLE_CLANG_REWRITER!$ENABLE_CLANG_REWRITER$ac_delim
ENABLE_OPTIMIZED!$ENABLE_OPTIMIZED$ac_delim
@ -20177,9 +20211,6 @@ ENABLE_WERROR!$ENABLE_WERROR$ac_delim
ENABLE_EXPENSIVE_CHECKS!$ENABLE_EXPENSIVE_CHECKS$ac_delim
EXPENSIVE_CHECKS!$EXPENSIVE_CHECKS$ac_delim
DEBUG_RUNTIME!$DEBUG_RUNTIME$ac_delim
DEBUG_SYMBOLS!$DEBUG_SYMBOLS$ac_delim
KEEP_SYMBOLS!$KEEP_SYMBOLS$ac_delim
JIT!$JIT$ac_delim
_ACEOF
if test `sed -n "s/.*$ac_delim\$/X/p" conf$$subs.sed | grep -c X` = 97; then
@ -20221,6 +20252,9 @@ _ACEOF
ac_delim='%!_!# '
for ac_last_try in false false false false false :; do
cat >conf$$subs.sed <<_ACEOF
DEBUG_SYMBOLS!$DEBUG_SYMBOLS$ac_delim
KEEP_SYMBOLS!$KEEP_SYMBOLS$ac_delim
JIT!$JIT$ac_delim
TARGET_HAS_JIT!$TARGET_HAS_JIT$ac_delim
TARGETS_WITH_JIT!$TARGETS_WITH_JIT$ac_delim
ENABLE_DOCS!$ENABLE_DOCS$ac_delim
@ -20315,9 +20349,6 @@ LLVM_ETCDIR!$LLVM_ETCDIR$ac_delim
LLVM_INCLUDEDIR!$LLVM_INCLUDEDIR$ac_delim
LLVM_INFODIR!$LLVM_INFODIR$ac_delim
LLVM_MANDIR!$LLVM_MANDIR$ac_delim
LLVM_CONFIGTIME!$LLVM_CONFIGTIME$ac_delim
BINDINGS_TO_BUILD!$BINDINGS_TO_BUILD$ac_delim
ALL_BINDINGS!$ALL_BINDINGS$ac_delim
_ACEOF
if test `sed -n "s/.*$ac_delim\$/X/p" conf$$subs.sed | grep -c X` = 97; then
@ -20359,6 +20390,9 @@ _ACEOF
ac_delim='%!_!# '
for ac_last_try in false false false false false :; do
cat >conf$$subs.sed <<_ACEOF
LLVM_CONFIGTIME!$LLVM_CONFIGTIME$ac_delim
BINDINGS_TO_BUILD!$BINDINGS_TO_BUILD$ac_delim
ALL_BINDINGS!$ALL_BINDINGS$ac_delim
OCAML_LIBDIR!$OCAML_LIBDIR$ac_delim
ENABLE_VISIBILITY_INLINES_HIDDEN!$ENABLE_VISIBILITY_INLINES_HIDDEN$ac_delim
RPATH!$RPATH$ac_delim
@ -20368,7 +20402,7 @@ LIBOBJS!$LIBOBJS$ac_delim
LTLIBOBJS!$LTLIBOBJS$ac_delim
_ACEOF
if test `sed -n "s/.*$ac_delim\$/X/p" conf$$subs.sed | grep -c X` = 7; then
if test `sed -n "s/.*$ac_delim\$/X/p" conf$$subs.sed | grep -c X` = 10; then
break
elif $ac_last_try; then
{ { echo "$as_me:$LINENO: error: could not make $CONFIG_STATUS" >&5

BIN
external/bsd/llvm/dist/llvm/docs/ARM-BE-bitcastfail.png vendored Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 29 KiB

BIN
external/bsd/llvm/dist/llvm/docs/ARM-BE-bitcastsuccess.png vendored Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 40 KiB

BIN
external/bsd/llvm/dist/llvm/docs/ARM-BE-ld1.png vendored Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 22 KiB

BIN
external/bsd/llvm/dist/llvm/docs/ARM-BE-ldr.png vendored Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 16 KiB

20
external/bsd/llvm/dist/llvm/docs/AliasAnalysis.rst vendored
View File

@ -51,7 +51,7 @@ starting address and size, and function calls are represented as the actual
get mod/ref information for arbitrary instructions.
All ``AliasAnalysis`` interfaces require that in queries involving multiple
values, values which are not `constants <LangRef.html#constants>`_ are all
values, values which are not :ref:`constants <constants>` are all
defined within the same function.
Representation of Pointers
@ -111,7 +111,7 @@ returns MustAlias, PartialAlias, MayAlias, or NoAlias as appropriate.
Like all ``AliasAnalysis`` interfaces, the ``alias`` method requires that either
the two pointer values be defined within the same function, or at least one of
the values is a `constant <LangRef.html#constants>`_.
the values is a :ref:`constant <constants>`.
.. _Must, May, or No:
@ -126,7 +126,7 @@ used for reading memory. Another is when the memory is freed and reallocated
between accesses through one pointer and accesses through the other --- in this
case, there is a dependence, but it's mediated by the free and reallocation.
As an exception to this is with the `noalias <LangRef.html#noalias>`_ keyword;
As an exception to this is with the :ref:`noalias <noalias>` keyword;
the "irrelevant" dependencies are ignored.
The ``MayAlias`` response is used whenever the two pointers might refer to the
@ -246,6 +246,20 @@ analysis run method (``run`` for a ``Pass``, ``runOnFunction`` for a
return false;
}
Required methods to override
----------------------------
You must override the ``getAdjustedAnalysisPointer`` method on all subclasses
of ``AliasAnalysis``. An example implementation of this method would look like:
.. code-block:: c++
void *getAdjustedAnalysisPointer(const void* ID) override {
if (ID == &AliasAnalysis::ID)
return (AliasAnalysis*)this;
return this;
}
Interfaces which may be specified
---------------------------------

205
external/bsd/llvm/dist/llvm/docs/BigEndianNEON.rst vendored Normal file
View File

@ -0,0 +1,205 @@
==============================================
Using ARM NEON instructions in big endian mode
==============================================
.. contents::
:local:
Introduction
============
Generating code for big endian ARM processors is for the most part straightforward. NEON loads and stores however have some interesting properties that make code generation decisions less obvious in big endian mode.
The aim of this document is to explain the problem with NEON loads and stores, and the solution that has been implemented in LLVM.
In this document the term "vector" refers to what the ARM ABI calls a "short vector", which is a sequence of items that can fit in a NEON register. This sequence can be 64 or 128 bits in length, and can constitute 8, 16, 32 or 64 bit items. This document refers to A64 instructions throughout, but is almost applicable to the A32/ARMv7 instruction sets also. The ABI format for passing vectors in A32 is sligtly different to A64. Apart from that, the same concepts apply.
Example: C-level intrinsics -> assembly
---------------------------------------
It may be helpful first to illustrate how C-level ARM NEON intrinsics are lowered to instructions.
This trivial C function takes a vector of four ints and sets the zero'th lane to the value "42"::
#include <arm_neon.h>
int32x4_t f(int32x4_t p) {
return vsetq_lane_s32(42, p, 0);
}
arm_neon.h intrinsics generate "generic" IR where possible (that is, normal IR instructions not ``llvm.arm.neon.*`` intrinsic calls). The above generates::
define <4 x i32> @f(<4 x i32> %p) {
%vset_lane = insertelement <4 x i32> %p, i32 42, i32 0
ret <4 x i32> %vset_lane
}
Which then becomes the following trivial assembly::
f: // @f
movz w8, #0x2a
ins v0.s[0], w8
ret
Problem
=======
The main problem is how vectors are represented in memory and in registers.
First, a recap. The "endianness" of an item affects its representation in memory only. In a register, a number is just a sequence of bits - 64 bits in the case of AArch64 general purpose registers. Memory, however, is a sequence of addressable units of 8 bits in size. Any number greater than 8 bits must therefore be split up into 8-bit chunks, and endianness describes the order in which these chunks are laid out in memory.
A "little endian" layout has the least significant byte first (lowest in memory address). A "big endian" layout has the *most* significant byte first. This means that when loading an item from big endian memory, the lowest 8-bits in memory must go in the most significant 8-bits, and so forth.
``LDR`` and ``LD1``
===================
.. figure:: ARM-BE-ldr.png
:align: right
Big endian vector load using ``LDR``.
A vector is a consecutive sequence of items that are operated on simultaneously. To load a 64-bit vector, 64 bits need to be read from memory. In little endian mode, we can do this by just performing a 64-bit load - ``LDR q0, [foo]``. However if we try this in big endian mode, because of the byte swapping the lane indices end up being swapped! The zero'th item as laid out in memory becomes the n'th lane in the vector.
.. figure:: ARM-BE-ld1.png
:align: right
Big endian vector load using ``LD1``. Note that the lanes retain the correct ordering.
Because of this, the instruction ``LD1`` performs a vector load but performs byte swapping not on the entire 64 bits, but on the individual items within the vector. This means that the register content is the same as it would have been on a little endian system.
It may seem that ``LD1`` should suffice to peform vector loads on a big endian machine. However there are pros and cons to the two approaches that make it less than simple which register format to pick.
There are two options:
1. The content of a vector register is the same *as if* it had been loaded with an ``LDR`` instruction.
2. The content of a vector register is the same *as if* it had been loaded with an ``LD1`` instruction.
Because ``LD1 == LDR + REV`` and similarly ``LDR == LD1 + REV`` (on a big endian system), we can simulate either type of load with the other type of load plus a ``REV`` instruction. So we're not deciding which instructions to use, but which format to use (which will then influence which instruction is best to use).
.. The 'clearer' container is required to make the following section header come after the floated
images above.
.. container:: clearer
Note that throughout this section we only mention loads. Stores have exactly the same problems as their associated loads, so have been skipped for brevity.
Considerations
==============
LLVM IR Lane ordering
---------------------
LLVM IR has first class vector types. In LLVM IR, the zero'th element of a vector resides at the lowest memory address. The optimizer relies on this property in certain areas, for example when concatenating vectors together. The intention is for arrays and vectors to have identical memory layouts - ``[4 x i8]`` and ``<4 x i8>`` should be represented the same in memory. Without this property there would be many special cases that the optimizer would have to cleverly handle.
Use of ``LDR`` would break this lane ordering property. This doesn't preclude the use of ``LDR``, but we would have to do one of two things:
1. Insert a ``REV`` instruction to reverse the lane order after every ``LDR``.
2. Disable all optimizations that rely on lane layout, and for every access to an individual lane (``insertelement``/``extractelement``/``shufflevector``) reverse the lane index.
AAPCS
-----
The ARM procedure call standard (AAPCS) defines the ABI for passing vectors between functions in registers. It states:
When a short vector is transferred between registers and memory it is treated as an opaque object. That is a short vector is stored in memory as if it were stored with a single ``STR`` of the entire register; a short vector is loaded from memory using the corresponding ``LDR`` instruction. On a little-endian system this means that element 0 will always contain the lowest addressed element of a short vector; on a big-endian system element 0 will contain the highest-addressed element of a short vector.
-- Procedure Call Standard for the ARM 64-bit Architecture (AArch64), 4.1.2 Short Vectors
The use of ``LDR`` and ``STR`` as the ABI defines has at least one advantage over ``LD1`` and ``ST1``. ``LDR`` and ``STR`` are oblivious to the size of the individual lanes of a vector. ``LD1`` and ``ST1`` are not - the lane size is encoded within them. This is important across an ABI boundary, because it would become necessary to know the lane width the callee expects. Consider the following code:
.. code-block:: c
<callee.c>
void callee(uint32x2_t v) {
...
}
<caller.c>
extern void callee(uint32x2_t);
void caller() {
callee(...);
}
If ``callee`` changed its signature to ``uint16x4_t``, which is equivalent in register content, if we passed as ``LD1`` we'd break this code until ``caller`` was updated and recompiled.
There is an argument that if the signatures of the two functions are different then the behaviour should be undefined. But there may be functions that are agnostic to the lane layout of the vector, and treating the vector as an opaque value (just loading it and storing it) would be impossible without a common format across ABI boundaries.
So to preserve ABI compatibility, we need to use the ``LDR`` lane layout across function calls.
Alignment
---------
In strict alignment mode, ``LDR qX`` requires its address to be 128-bit aligned, whereas ``LD1`` only requires it to be as aligned as the lane size. If we canonicalised on using ``LDR``, we'd still need to use ``LD1`` in some places to avoid alignment faults (the result of the ``LD1`` would then need to be reversed with ``REV``).
Most operating systems however do not run with alignment faults enabled, so this is often not an issue.
Summary
-------
The following table summarises the instructions that are required to be emitted for each property mentioned above for each of the two solutions.
+-------------------------------+-------------------------------+---------------------+
| | ``LDR`` layout | ``LD1`` layout |
+===============================+===============================+=====================+
| Lane ordering | ``LDR + REV`` | ``LD1`` |
+-------------------------------+-------------------------------+---------------------+
| AAPCS | ``LDR`` | ``LD1 + REV`` |
+-------------------------------+-------------------------------+---------------------+
| Alignment for strict mode | ``LDR`` / ``LD1 + REV`` | ``LD1`` |
+-------------------------------+-------------------------------+---------------------+
Neither approach is perfect, and choosing one boils down to choosing the lesser of two evils. The issue with lane ordering, it was decided, would have to change target-agnostic compiler passes and would result in a strange IR in which lane indices were reversed. It was decided that this was worse than the changes that would have to be made to support ``LD1``, so ``LD1`` was chosen as the canonical vector load instruction (and by inference, ``ST1`` for vector stores).
Implementation
==============
There are 3 parts to the implementation:
1. Predicate ``LDR`` and ``STR`` instructions so that they are never allowed to be selected to generate vector loads and stores. The exception is one-lane vectors [1]_ - these by definition cannot have lane ordering problems so are fine to use ``LDR``/``STR``.
2. Create code generation patterns for bitconverts that create ``REV`` instructions.
3. Make sure appropriate bitconverts are created so that vector values get passed over call boundaries as 1-element vectors (which is the same as if they were loaded with ``LDR``).
Bitconverts
-----------
.. image:: ARM-BE-bitcastfail.png
:align: right
The main problem with the ``LD1`` solution is dealing with bitconverts (or bitcasts, or reinterpret casts). These are pseudo instructions that only change the compiler's interpretation of data, not the underlying data itself. A requirement is that if data is loaded and then saved again (called a "round trip"), the memory contents should be the same after the store as before the load. If a vector is loaded and is then bitconverted to a different vector type before storing, the round trip will currently be broken.
Take for example this code sequence::
%0 = load <4 x i32> %x
%1 = bitcast <4 x i32> %0 to <2 x i64>
store <2 x i64> %1, <2 x i64>* %y
This would produce a code sequence such as that in the figure on the right. The mismatched ``LD1`` and ``ST1`` cause the stored data to differ from the loaded data.
.. container:: clearer
When we see a bitcast from type ``X`` to type ``Y``, what we need to do is to change the in-register representation of the data to be *as if* it had just been loaded by a ``LD1`` of type ``Y``.
.. image:: ARM-BE-bitcastsuccess.png
:align: right
Conceptually this is simple - we can insert a ``REV`` undoing the ``LD1`` of type ``X`` (converting the in-register representation to the same as if it had been loaded by ``LDR``) and then insert another ``REV`` to change the representation to be as if it had been loaded by an ``LD1`` of type ``Y``.
For the previous example, this would be::
LD1 v0.4s, [x]
REV64 v0.4s, v0.4s // There is no REV128 instruction, so it must be synthesizedcd
EXT v0.16b, v0.16b, v0.16b, #8 // with a REV64 then an EXT to swap the two 64-bit elements.
REV64 v0.2d, v0.2d
EXT v0.16b, v0.16b, v0.16b, #8
ST1 v0.2d, [y]
It turns out that these ``REV`` pairs can, in almost all cases, be squashed together into a single ``REV``. For the example above, a ``REV128 4s`` + ``REV128 2d`` is actually a ``REV64 4s``, as shown in the figure on the right.
.. [1] One lane vectors may seem useless as a concept but they serve to distinguish between values held in general purpose registers and values held in NEON/VFP registers. For example, an ``i64`` would live in an ``x`` register, but ``<1 x i64>`` would live in a ``d`` register.

7
external/bsd/llvm/dist/llvm/docs/BitCodeFormat.rst vendored
View File

@ -688,7 +688,8 @@ global variable. The operand fields are:
* ``weak_odr``: code 10
* ``linkonce_odr``: code 11
* ``available_externally``: code 12
* ``linker_private``: code 13
* deprecated : code 13
* deprecated : code 14
* alignment*: The logarithm base 2 of the variable's requested alignment, plus 1
@ -746,8 +747,6 @@ function. The operand fields are:
* ``arm_apcscc``: code 66
* ``arm_aapcscc``: code 67
* ``arm_aapcs_vfpcc``: code 68
* ``x86_thiscallcc``: code 70
* ``x86_cdeclmethodcc``: code 80
* isproto*: Non-zero if this entry represents a declaration rather than a
definition
@ -1094,7 +1093,7 @@ named type.
VALUE_SYMTAB_BLOCK Contents
---------------------------
The ``VALUE_SYMTAB_BLOCK`` block (id 14) ...
The ``VALUE_SYMTAB_BLOCK`` block (id 14) ...
.. _METADATA_BLOCK:

130
external/bsd/llvm/dist/llvm/docs/BlockFrequencyTerminology.rst vendored Normal file
View File

@ -0,0 +1,130 @@
================================
LLVM Block Frequency Terminology
================================
.. contents::
:local:
Introduction
============
Block Frequency is a metric for estimating the relative frequency of different
basic blocks. This document describes the terminology that the
``BlockFrequencyInfo`` and ``MachineBlockFrequencyInfo`` analysis passes use.
Branch Probability
==================
Blocks with multiple successors have probabilities associated with each
outgoing edge. These are called branch probabilities. For a given block, the
sum of its outgoing branch probabilities should be 1.0.
Branch Weight
=============
Rather than storing fractions on each edge, we store an integer weight.
Weights are relative to the other edges of a given predecessor block. The
branch probability associated with a given edge is its own weight divided by
the sum of the weights on the predecessor's outgoing edges.
For example, consider this IR:
.. code-block:: llvm
define void @foo() {
; ...
A:
br i1 %cond, label %B, label %C, !prof !0
; ...
}
!0 = metadata !{metadata !"branch_weights", i32 7, i32 8}
and this simple graph representation::
A -> B (edge-weight: 7)
A -> C (edge-weight: 8)
The probability of branching from block A to block B is 7/15, and the
probability of branching from block A to block C is 8/15.
See :doc:`BranchWeightMetadata` for details about the branch weight IR
representation.
Block Frequency
===============
Block frequency is a relative metric that represents the number of times a
block executes. The ratio of a block frequency to the entry block frequency is
the expected number of times the block will execute per entry to the function.
Block frequency is the main output of the ``BlockFrequencyInfo`` and
``MachineBlockFrequencyInfo`` analysis passes.
Implementation: a series of DAGs
================================
The implementation of the block frequency calculation analyses each loop,
bottom-up, ignoring backedges; i.e., as a DAG. After each loop is processed,
it's packaged up to act as a pseudo-node in its parent loop's (or the
function's) DAG analysis.
Block Mass
==========
For each DAG, the entry node is assigned a mass of ``UINT64_MAX`` and mass is
distributed to successors according to branch weights. Block Mass uses a
fixed-point representation where ``UINT64_MAX`` represents ``1.0`` and ``0``
represents a number just above ``0.0``.
After mass is fully distributed, in any cut of the DAG that separates the exit
nodes from the entry node, the sum of the block masses of the nodes succeeded
by a cut edge should equal ``UINT64_MAX``. In other words, mass is conserved
as it "falls" through the DAG.
If a function's basic block graph is a DAG, then block masses are valid block
frequencies. This works poorly in practise though, since downstream users rely
on adding block frequencies together without hitting the maximum.
Loop Scale
==========
Loop scale is a metric that indicates how many times a loop iterates per entry.
As mass is distributed through the loop's DAG, the (otherwise ignored) backedge
mass is collected. This backedge mass is used to compute the exit frequency,
and thus the loop scale.
Implementation: Getting from mass and scale to frequency
========================================================
After analysing the complete series of DAGs, each block has a mass (local to
its containing loop, if any), and each loop pseudo-node has a loop scale and
its own mass (from its parent's DAG).
We can get an initial frequency assignment (with entry frequency of 1.0) by
multiplying these masses and loop scales together. A given block's frequency
is the product of its mass, the mass of containing loops' pseudo nodes, and the
containing loops' loop scales.
Since downstream users need integers (not floating point), this initial
frequency assignment is shifted as necessary into the range of ``uint64_t``.
Block Bias
==========
Block bias is a proposed *absolute* metric to indicate a bias toward or away
from a given block during a function's execution. The idea is that bias can be
used in isolation to indicate whether a block is relatively hot or cold, or to
compare two blocks to indicate whether one is hotter or colder than the other.
The proposed calculation involves calculating a *reference* block frequency,
where:
* every branch weight is assumed to be 1 (i.e., every branch probability
distribution is even) and
* loop scales are ignored.
This reference frequency represents what the block frequency would be in an
unbiased graph.
The bias is the ratio of the block frequency to this reference block frequency.

9
external/bsd/llvm/dist/llvm/docs/BranchWeightMetadata.rst vendored
View File

@ -8,10 +8,11 @@ LLVM Branch Weight Metadata
Introduction
============
Branch Weight Metadata represents branch weights as its likeliness to be
taken. Metadata is assigned to the ``TerminatorInst`` as a ``MDNode`` of the
``MD_prof`` kind. The first operator is always a ``MDString`` node with the
string "branch_weights". Number of operators depends on the terminator type.
Branch Weight Metadata represents branch weights as its likeliness to be taken
(see :doc:`BlockFrequencyTerminology`). Metadata is assigned to the
``TerminatorInst`` as a ``MDNode`` of the ``MD_prof`` kind. The first operator
is always a ``MDString`` node with the string "branch_weights". Number of
operators depends on the terminator type.
Branch weights might be fetch from the profiling file, or generated based on
`__builtin_expect`_ instruction.

2
external/bsd/llvm/dist/llvm/docs/Bugpoint.rst vendored
View File

@ -17,7 +17,7 @@ optimization (or combination of optimizations) that causes the crash, and reduce
the file down to a small example which triggers the crash.
For detailed case scenarios, such as debugging ``opt``, or one of the LLVM code
generators, see `How To Submit a Bug Report document <HowToSubmitABug.html>`_.
generators, see :doc:`HowToSubmitABug`.
Design Philosophy
=================

86
external/bsd/llvm/dist/llvm/docs/CMake.rst vendored
View File

@ -87,7 +87,7 @@ names are case-sensitive. Example:
.. code-block:: console
$ cmake -G "Visual Studio 10" path/to/llvm/source/root
$ cmake -G "Visual Studio 11" path/to/llvm/source/root
For a given development platform there can be more than one adequate
generator. If you use Visual Studio "NMake Makefiles" is a generator you can use
@ -132,7 +132,7 @@ write the variable and the type on the CMake command line:
Frequently-used CMake variables
-------------------------------
Here are listed some of the CMake variables that are used often, along with a
Here are some of the CMake variables that are used often, along with a
brief explanation and LLVM-specific notes. For full documentation, check the
CMake docs or execute ``cmake --help-variable VARIABLE_NAME``.
@ -157,8 +157,8 @@ CMake docs or execute ``cmake --help-variable VARIABLE_NAME``.
Extra flags to use when compiling C++ source files.
**BUILD_SHARED_LIBS**:BOOL
Flag indicating is shared libraries will be built. Its default value is
OFF. Shared libraries are not supported on Windows and not recommended in the
Flag indicating if shared libraries will be built. Its default value is
OFF. Shared libraries are not supported on Windows and not recommended on the
other OSes.
.. _LLVM-specific variables:
@ -211,8 +211,8 @@ LLVM-specific variables
**LLVM_ENABLE_THREADS**:BOOL
Build with threads support, if available. Defaults to ON.
**LLVM_ENABLE_CXX11**:BOOL
Build in C++11 mode, if available. Defaults to OFF.
**LLVM_ENABLE_CXX1Y**:BOOL
Build in C++1y mode, if available. Defaults to OFF.
**LLVM_ENABLE_ASSERTIONS**:BOOL
Enables code assertions. Defaults to OFF if and only if ``CMAKE_BUILD_TYPE``
@ -266,7 +266,7 @@ LLVM-specific variables
**LLVM_EXTERNAL_{CLANG,LLD,POLLY}_SOURCE_DIR**:PATH
Path to ``{Clang,lld,Polly}``\'s source directory. Defaults to
``tools/{clang,lld,polly}``. ``{Clang,lld,Polly}`` will not be built when it
is empty or it does not point valid path.
is empty or it does not point to a valid path.
**LLVM_USE_OPROFILE**:BOOL
Enable building OProfile JIT support. Defaults to OFF
@ -283,6 +283,78 @@ LLVM-specific variables
are ``Address``, ``Memory`` and ``MemoryWithOrigins``. Defaults to empty
string.
**LLVM_BUILD_DOCS**:BOOL
Enables all enabled documentation targets (i.e. Doxgyen and Sphinx targets) to
be built as part of the normal build. If the ``install`` target is run then
this also enables all built documentation targets to be installed. Defaults to
OFF.
**LLVM_ENABLE_DOXYGEN**:BOOL
Enables the generation of browsable HTML documentation using doxygen.
Defaults to OFF.
**LLVM_ENABLE_DOXYGEN_QT_HELP**:BOOL
Enables the generation of a Qt Compressed Help file. Defaults to OFF.
This affects the make target ``doxygen-llvm``. When enabled, apart from
the normal HTML output generated by doxygen, this will produce a QCH file
named ``org.llvm.qch``. You can then load this file into Qt Creator.
This option is only useful in combination with ``-DLLVM_ENABLE_DOXYGEN=ON``;
otherwise this has no effect.
**LLVM_DOXYGEN_QCH_FILENAME**:STRING
The filename of the Qt Compressed Help file that will be genrated when
``-DLLVM_ENABLE_DOXYGEN=ON`` and
``-DLLVM_ENABLE_DOXYGEN_QT_HELP=ON`` are given. Defaults to
``org.llvm.qch``.
This option is only useful in combination with
``-DLLVM_ENABLE_DOXYGEN_QT_HELP=ON``;
otherwise this has no effect.
**LLVM_DOXYGEN_QHP_NAMESPACE**:STRING
Namespace under which the intermediate Qt Help Project file lives. See `Qt
Help Project`_
for more information. Defaults to "org.llvm". This option is only useful in
combination with ``-DLLVM_ENABLE_DOXYGEN_QT_HELP=ON``; otherwise
this has no effect.
**LLVM_DOXYGEN_QHP_CUST_FILTER_NAME**:STRING
See `Qt Help Project`_ for
more information. Defaults to the CMake variable ``${PACKAGE_STRING}`` which
is a combination of the package name and version string. This filter can then
be used in Qt Creator to select only documentation from LLVM when browsing
through all the help files that you might have loaded. This option is only
useful in combination with ``-DLLVM_ENABLE_DOXYGEN_QT_HELP=ON``;
otherwise this has no effect.
.. _Qt Help Project: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-filters
**LLVM_DOXYGEN_QHELPGENERATOR_PATH**:STRING
The path to the ``qhelpgenerator`` executable. Defaults to whatever CMake's
``find_program()`` can find. This option is only useful in combination with
``-DLLVM_ENABLE_DOXYGEN_QT_HELP=ON``; otherwise this has no
effect.
**LLVM_ENABLE_SPHINX**:BOOL
If enabled CMake will search for the ``sphinx-build`` executable and will make
the ``SPHINX_OUTPUT_HTML`` and ``SPHINX_OUTPUT_MAN`` CMake options available.
Defaults to OFF.
**SPHINX_EXECUTABLE**:STRING
The path to the ``sphinx-build`` executable detected by CMake.
**SPHINX_OUTPUT_HTML**:BOOL
If enabled (and ``LLVM_ENABLE_SPHINX`` is enabled) then the targets for
building the documentation as html are added (but not built by default unless
``LLVM_BUILD_DOCS`` is enabled). There is a target for each project in the
source tree that uses sphinx (e.g. ``docs-llvm-html``, ``docs-clang-html``
and ``docs-lld-html``). Defaults to ON.
**SPHINX_OUTPUT_MAN**:BOOL
If enabled (and ``LLVM_ENABLE_SPHINX`` is enabled) the targets for building
the man pages are added (but not built by default unless ``LLVM_BUILD_DOCS``
is enabled). Currently the only target added is ``docs-llvm-man``. Defaults
to ON.
Executing the test suite
========================

55
external/bsd/llvm/dist/llvm/docs/CMakeLists.txt vendored
View File

@ -22,6 +22,40 @@ if (LLVM_ENABLE_DOXYGEN)
set(extra_search_mappings "")
endif()
# If asked, configure doxygen for the creation of a Qt Compressed Help file.
option(LLVM_ENABLE_DOXYGEN_QT_HELP
"Generate a Qt Compressed Help file." OFF)
if (LLVM_ENABLE_DOXYGEN_QT_HELP)
set(LLVM_DOXYGEN_QCH_FILENAME "org.llvm.qch" CACHE STRING
"Filename of the Qt Compressed help file")
set(LLVM_DOXYGEN_QHP_NAMESPACE "org.llvm" CACHE STRING
"Namespace under which the intermediate Qt Help Project file lives")
set(LLVM_DOXYGEN_QHP_CUST_FILTER_NAME "${PACKAGE_STRING}" CACHE STRING
"See http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-filters")
set(LLVM_DOXYGEN_QHP_CUST_FILTER_ATTRS "${PACKAGE_NAME},${PACKAGE_VERSION}" CACHE STRING
"See http://qt-project.org/doc/qt-4.8/qthelpproject.html#filter-attributes")
find_program(LLVM_DOXYGEN_QHELPGENERATOR_PATH qhelpgenerator
DOC "Path to the qhelpgenerator binary")
if (NOT LLVM_DOXYGEN_QHELPGENERATOR_PATH)
message(FATAL_ERROR "Failed to find qhelpgenerator binary")
endif()
set(llvm_doxygen_generate_qhp "YES")
set(llvm_doxygen_qch_filename "${LLVM_DOXYGEN_QCH_FILENAME}")
set(llvm_doxygen_qhp_namespace "${LLVM_DOXYGEN_QHP_NAMESPACE}")
set(llvm_doxygen_qhelpgenerator_path "${LLVM_DOXYGEN_QHELPGENERATOR_PATH}")
set(llvm_doxygen_qhp_cust_filter_name "${LLVM_DOXYGEN_QHP_CUST_FILTER_NAME}")
set(llvm_doxygen_qhp_cust_filter_attrs "${LLVM_DOXYGEN_QHP_CUST_FILTER_ATTRS}")
else()
set(llvm_doxygen_generate_qhp "NO")
set(llvm_doxygen_qch_filename "")
set(llvm_doxygen_qhp_namespace "")
set(llvm_doxygen_qhelpgenerator_path "")
set(llvm_doxygen_qhp_cust_filter_name "")
set(llvm_doxygen_qhp_cust_filter_attrs "")
endif()
configure_file(${CMAKE_CURRENT_SOURCE_DIR}/doxygen.cfg.in
${CMAKE_CURRENT_BINARY_DIR}/doxygen.cfg @ONLY)
@ -33,6 +67,12 @@ if (LLVM_ENABLE_DOXYGEN)
set(enable_server_based_search)
set(enable_external_search)
set(extra_search_mappings)
set(llvm_doxygen_generate_qhp)
set(llvm_doxygen_qch_filename)
set(llvm_doxygen_qhp_namespace)
set(llvm_doxygen_qhelpgenerator_path)
set(llvm_doxygen_qhp_cust_filter_name)
set(llvm_doxygen_qhp_cust_filter_attrs)
add_custom_target(doxygen-llvm
COMMAND ${DOXYGEN_EXECUTABLE} ${CMAKE_CURRENT_BINARY_DIR}/doxygen.cfg
@ -49,3 +89,18 @@ if (LLVM_ENABLE_DOXYGEN)
endif()
endif()
endif()
if (LLVM_ENABLE_SPHINX)
if (SPHINX_FOUND)
include(AddSphinxTarget)
if (${SPHINX_OUTPUT_HTML})
add_sphinx_target(html llvm)
endif()
if (${SPHINX_OUTPUT_MAN})
add_sphinx_target(man llvm)
endif()
endif()
endif()

14
external/bsd/llvm/dist/llvm/docs/CodeGenerator.rst vendored
View File

@ -70,7 +70,7 @@ different pieces of this will be useful to you. In any case, you should be
familiar with the `target description`_ and `machine code representation`_
classes. If you want to add a backend for a new target, you will need to
`implement the target description`_ classes for your new target and understand
the `LLVM code representation <LangRef.html>`_. If you are interested in
the :doc:`LLVM code representation <LangRef>`. If you are interested in
implementing a new `code generation algorithm`_, it should only depend on the
target-description and machine code representation classes, ensuring that it is
portable.
@ -172,7 +172,7 @@ architecture. These target descriptions often have a large amount of common
information (e.g., an ``add`` instruction is almost identical to a ``sub``
instruction). In order to allow the maximum amount of commonality to be
factored out, the LLVM code generator uses the
:doc:`TableGen <TableGenFundamentals>` tool to describe big chunks of the
:doc:`TableGen/index` tool to describe big chunks of the
target machine, which allows the use of domain-specific and target-specific
abstractions to reduce the amount of repetition.
@ -277,7 +277,7 @@ an associated register class. When the register allocator runs, it replaces
virtual registers with a physical register in the set.
The target-specific implementations of these classes is auto-generated from a
`TableGen <TableGenFundamentals.html>`_ description of the register file.
:doc:`TableGen/index` description of the register file.
.. _TargetInstrInfo:
@ -1993,7 +1993,7 @@ Tail Calls
This box indicates whether the target supports guaranteed tail calls. These are
calls marked "`tail <LangRef.html#i_call>`_" and use the fastcc calling
convention. Please see the `tail call section more more details`_.
convention. Please see the `tail call section`_ for more details.
.. _feat_segstacks:
@ -2011,7 +2011,7 @@ Basic support exists on the X86 backend. Currently vararg doesn't work and the
object files are not marked the way the gold linker expects, but simple Go
programs can be built by dragonegg.
.. _tail call section more more details:
.. _tail call section:
Tail call optimization
----------------------
@ -2145,10 +2145,6 @@ The following target-specific calling conventions are known to backend:
others via stack. Callee is responsible for stack cleaning. This convention is
used by MSVC by default for methods in its ABI (CC ID = 70).
* **X86_CDeclMethod** --- Identical to the standard x86_32 C calling convention,
except that an sret paramter, if present, is placed on the stack after the
second parameter, which must an integer or pointer. (CC ID = 80).
.. _X86 addressing mode:
Representing X86 addressing modes in MachineInstrs

223
external/bsd/llvm/dist/llvm/docs/CodingStandards.rst vendored
View File

@ -76,13 +76,10 @@ implemented in the LLVM namespace following the expected standard interface.
There are some exceptions such as the standard I/O streams library which are
avoided. Also, there is much more detailed information on these subjects in the
`Programmer's Manual`_.
.. _Programmer's Manual:
http://llvm.org/docs/ProgrammersManual.html
:doc:`ProgrammersManual`.
Supported C++11 Language and Library Features
-------------------------------------------
---------------------------------------------
While LLVM, Clang, and LLD use C++11, not all features are available in all of
the toolchains which we support. The set of features supported for use in LLVM
@ -109,6 +106,12 @@ unlikely to be supported by our host compilers.
* ``auto`` type deduction: N1984_, N1737_
* Trailing return types: N2541_
* Lambdas: N2927_
* But *not* ``std::function``, until Clang implements `MSVC-compatible RTTI`_.
In many cases, you may be able to use ``llvm::function_ref`` instead, and it
is a superior choice in those cases.
* And *not* lambdas with default arguments.
* ``decltype``: N2343_
* Nested closing right angle brackets: N1757_
* Extern templates: N1987_
@ -116,6 +119,11 @@ unlikely to be supported by our host compilers.
* Strongly-typed and forward declarable enums: N2347_, N2764_
* Local and unnamed types as template arguments: N2657_
* Range-based for-loop: N2930_
* But ``{}`` are required around inner ``do {} while()`` loops. As a result,
``{}`` are required around function-like macros inside range-based for
loops.
* ``override`` and ``final``: N2928_, N3206_, N3272_
* Atomic operations and the C++11 memory model: N2429_
@ -138,6 +146,7 @@ unlikely to be supported by our host compilers.
.. _N3206: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3206.htm
.. _N3272: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3272.htm
.. _N2429: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2429.htm
.. _MSVC-compatible RTTI: http://llvm.org/PR18951
The supported features in the C++11 standard libraries are less well tracked,
but also much greater. Most of the standard libraries implement most of C++11's
@ -153,6 +162,9 @@ being aware of:
* While most of the atomics library is well implemented, the fences are
missing. Fortunately, they are rarely needed.
* The locale support is incomplete.
* ``std::initializer_list`` (and the constructors and functions that take it as
an argument) are not always available, so you cannot (for example) initialize
a ``std::vector`` with a braced initializer list.
Other than these areas you should assume the standard library is available and
working as expected until some build bot tells you otherwise. If you're in an
@ -457,11 +469,88 @@ Indent Code Consistently
^^^^^^^^^^^^^^^^^^^^^^^^
Okay, in your first year of programming you were told that indentation is
important. If you didn't believe and internalize this then, now is the time.
Just do it.
important. If you didn't believe and internalize this then, now is the time.
Just do it. With the introduction of C++11, there are some new formatting
challenges that merit some suggestions to help have consistent, maintainable,
and tool-friendly formatting and indentation.
Compiler Issues
---------------
Format Lambdas Like Blocks Of Code
""""""""""""""""""""""""""""""""""
When formatting a multi-line lambda, format it like a block of code, that's
what it is. If there is only one multi-line lambda in a statement, and there
are no expressions lexically after it in the statement, drop the indent to the
standard two space indent for a block of code, as if it were an if-block opened
by the preceding part of the statement:
.. code-block:: c++
std::sort(foo.begin(), foo.end(), [&](Foo a, Foo b) -> bool {
if (a.blah < b.blah)
return true;
if (a.baz < b.baz)
return true;
return a.bam < b.bam;
});
To take best advantage of this formatting, if you are designing an API which
accepts a continuation or single callable argument (be it a functor, or
a ``std::function``), it should be the last argument if at all possible.
If there are multiple multi-line lambdas in a statement, or there is anything
interesting after the lambda in the statement, indent the block two spaces from
the indent of the ``[]``:
.. code-block:: c++
dyn_switch(V->stripPointerCasts(),
[] (PHINode *PN) {
// process phis...
},
[] (SelectInst *SI) {
// process selects...
},
[] (LoadInst *LI) {
// process loads...
},
[] (AllocaInst *AI) {
// process allocas...
});
Braced Initializer Lists
""""""""""""""""""""""""
With C++11, there are significantly more uses of braced lists to perform
initialization. These allow you to easily construct aggregate temporaries in
expressions among other niceness. They now have a natural way of ending up
nested within each other and within function calls in order to build up
aggregates (such as option structs) from local variables. To make matters
worse, we also have many more uses of braces in an expression context that are
*not* performing initialization.
The historically common formatting of braced initialization of aggregate
variables does not mix cleanly with deep nesting, general expression contexts,
function arguments, and lambdas. We suggest new code use a simple rule for
formatting braced initialization lists: act as-if the braces were parentheses
in a function call. The formatting rules exactly match those already well
understood for formatting nested function calls. Examples:
.. code-block:: c++
foo({a, b, c}, {1, 2, 3});
llvm::Constant *Mask[] = {
llvm::ConstantInt::get(llvm::Type::getInt32Ty(getLLVMContext()), 0),
llvm::ConstantInt::get(llvm::Type::getInt32Ty(getLLVMContext()), 1),
llvm::ConstantInt::get(llvm::Type::getInt32Ty(getLLVMContext()), 2)};
This formatting scheme also makes it particularly easy to get predictable,
consistent, and automatic formatting with tools like `Clang Format`_.
.. _Clang Format: http://clang.llvm.org/docs/ClangFormat.html
Language and Compiler Issues
----------------------------
Treat Compiler Warnings Like Errors
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@ -521,7 +610,7 @@ is never used for a class. Because of this, we turn them off globally in the
code.
That said, LLVM does make extensive use of a hand-rolled form of RTTI that use
templates like `isa<>, cast<>, and dyn_cast<> <ProgrammersManual.html#isa>`_.
templates like :ref:`isa\<>, cast\<>, and dyn_cast\<> <isa>`.
This form of RTTI is opt-in and can be
:doc:`added to any class <HowToSetUpLLVMStyleRTTI>`. It is also
substantially more efficient than ``dynamic_cast<>``.
@ -573,12 +662,110 @@ members public by default.
Unfortunately, not all compilers follow the rules and some will generate
different symbols based on whether ``class`` or ``struct`` was used to declare
the symbol. This can lead to problems at link time.
the symbol (e.g., MSVC). This can lead to problems at link time.
So, the rule for LLVM is to always use the ``class`` keyword, unless **all**
members are public and the type is a C++ `POD
<http://en.wikipedia.org/wiki/Plain_old_data_structure>`_ type, in which case
``struct`` is allowed.
* All declarations and definitions of a given ``class`` or ``struct`` must use
the same keyword. For example:
.. code-block:: c++
class Foo;
// Breaks mangling in MSVC.
struct Foo { int Data; };
* As a rule of thumb, ``struct`` should be kept to structures where *all*
members are declared public.
.. code-block:: c++
// Foo feels like a class... this is strange.
struct Foo {
private:
int Data;
public:
Foo() : Data(0) { }
int getData() const { return Data; }
void setData(int D) { Data = D; }
};
// Bar isn't POD, but it does look like a struct.
struct Bar {
int Data;
Foo() : Data(0) { }
};
Do not use Braced Initializer Lists to Call a Constructor
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In C++11 there is a "generalized initialization syntax" which allows calling
constructors using braced initializer lists. Do not use these to call
constructors with any interesting logic or if you care that you're calling some
*particular* constructor. Those should look like function calls using
parentheses rather than like aggregate initialization. Similarly, if you need
to explicitly name the type and call its constructor to create a temporary,
don't use a braced initializer list. Instead, use a braced initializer list
(without any type for temporaries) when doing aggregate initialization or
something notionally equivalent. Examples:
.. code-block:: c++
class Foo {
public:
// Construct a Foo by reading data from the disk in the whizbang format, ...
Foo(std::string filename);
// Construct a Foo by looking up the Nth element of some global data ...
Foo(int N);
// ...
};
// The Foo constructor call is very deliberate, no braces.
std::fill(foo.begin(), foo.end(), Foo("name"));
// The pair is just being constructed like an aggregate, use braces.
bar_map.insert({my_key, my_value});
If you use a braced initializer list when initializing a variable, use an equals before the open curly brace:
.. code-block:: c++
int data[] = {0, 1, 2, 3};
Use ``auto`` Type Deduction to Make Code More Readable
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Some are advocating a policy of "almost always ``auto``" in C++11, however LLVM
uses a more moderate stance. Use ``auto`` if and only if it makes the code more
readable or easier to maintain. Don't "almost always" use ``auto``, but do use
``auto`` with initializers like ``cast<Foo>(...)`` or other places where the
type is already obvious from the context. Another time when ``auto`` works well
for these purposes is when the type would have been abstracted away anyways,
often behind a container's typedef such as ``std::vector<T>::iterator``.
Beware unnecessary copies with ``auto``
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The convenience of ``auto`` makes it easy to forget that its default behavior
is a copy. Particularly in range-based ``for`` loops, careless copies are
expensive.
As a rule of thumb, use ``auto &`` unless you need to copy the result, and use
``auto *`` when copying pointers.
.. code-block:: c++
// Typically there's no reason to copy.
for (const auto &Val : Container) { observe(Val); }
for (auto &Val : Container) { Val.change(); }
// Remove the reference if you really want a new copy.
for (auto Val : Container) { Val.change(); saveSomewhere(Val); }
// Copy pointers, but make it clear that they're pointers.
for (const auto *Ptr : Container) { observe(*Ptr); }
for (auto *Ptr : Container) { Ptr->change(); }
Style Issues
============
@ -1099,9 +1286,9 @@ method will never be implemented. This enables other checks like
``-Wunused-private-field`` to run correctly on classes that contain these
methods.
To maintain compatibility with C++03, ``LLVM_DELETED_FUNCTION`` should be used
which will expand to ``= delete`` if the compiler supports it. These methods
should still be declared private. Example of the uncopyable pattern:
For compatibility with MSVC, ``LLVM_DELETED_FUNCTION`` should be used which
will expand to ``= delete`` on compilers that support it. These methods should
still be declared private. Example of the uncopyable pattern:
.. code-block:: c++

1
external/bsd/llvm/dist/llvm/docs/CommandGuide/index.rst vendored
View File

@ -28,6 +28,7 @@ Basic Commands
llvm-profdata
llvm-stress
llvm-symbolizer
llvm-dwarfdump
Debugging Tools
~~~~~~~~~~~~~~~

5
external/bsd/llvm/dist/llvm/docs/CommandGuide/llc.rst vendored
View File

@ -112,11 +112,6 @@ End-user Options
optimizations allow the code generator to make use of some instructions which
would otherwise not be usable (such as ``fsin`` on X86).
.. option:: --enable-correct-eh-support
Instruct the **lowerinvoke** pass to insert code for correct exception
handling support. This is expensive and is by default omitted for efficiency.
.. option:: --stats
Print statistics recorded by code-generation passes.

6
external/bsd/llvm/dist/llvm/docs/CommandGuide/lli.rst vendored
View File

@ -190,12 +190,6 @@ CODE GENERATION OPTIONS
**-enable-correct-eh-support**
Make the -lowerinvoke pass insert expensive, but correct, EH code.
**-jit-enable-eh**
Exception handling should be enabled in the just-in-time compiler.

114
external/bsd/llvm/dist/llvm/docs/CommandGuide/llvm-cov.rst vendored
View File

@ -4,32 +4,120 @@ llvm-cov - emit coverage information
SYNOPSIS
--------
:program:`llvm-cov` [-gcno=filename] [-gcda=filename] [dump]
:program:`llvm-cov` [options] SOURCEFILE
DESCRIPTION
-----------
The experimental :program:`llvm-cov` tool reads in description file generated
by compiler and coverage data file generated by instrumented program. This
program assumes that the description and data file uses same format as gcov
files.
The :program:`llvm-cov` tool reads code coverage data files and displays the
coverage information for a specified source file. It is compatible with the
``gcov`` tool from version 4.2 of ``GCC`` and may also be compatible with
some later versions of ``gcov``.
To use llvm-cov, you must first build an instrumented version of your
application that collects coverage data as it runs. Compile with the
``-fprofile-arcs`` and ``-ftest-coverage`` options to add the
instrumentation. (Alternatively, you can use the ``--coverage`` option, which
includes both of those other options.) You should compile with debugging
information (``-g``) and without optimization (``-O0``); otherwise, the
coverage data cannot be accurately mapped back to the source code.
At the time you compile the instrumented code, a ``.gcno`` data file will be
generated for each object file. These ``.gcno`` files contain half of the
coverage data. The other half of the data comes from ``.gcda`` files that are
generated when you run the instrumented program, with a separate ``.gcda``
file for each object file. Each time you run the program, the execution counts
are summed into any existing ``.gcda`` files, so be sure to remove any old
files if you do not want their contents to be included.
By default, the ``.gcda`` files are written into the same directory as the
object files, but you can override that by setting the ``GCOV_PREFIX`` and
``GCOV_PREFIX_STRIP`` environment variables. The ``GCOV_PREFIX_STRIP``
variable specifies a number of directory components to be removed from the
start of the absolute path to the object file directory. After stripping those
directories, the prefix from the ``GCOV_PREFIX`` variable is added. These
environment variables allow you to run the instrumented program on a machine
where the original object file directories are not accessible, but you will
then need to copy the ``.gcda`` files back to the object file directories
where llvm-cov expects to find them.
Once you have generated the coverage data files, run llvm-cov for each main
source file where you want to examine the coverage results. This should be run
from the same directory where you previously ran the compiler. The results for
the specified source file are written to a file named by appending a ``.gcov``
suffix. A separate output file is also created for each file included by the
main source file, also with a ``.gcov`` suffix added.
The basic content of an llvm-cov output file is a copy of the source file with
an execution count and line number prepended to every line. The execution
count is shown as ``-`` if a line does not contain any executable code. If
a line contains code but that code was never executed, the count is displayed
as ``#####``.
OPTIONS
-------
.. option:: -gcno=filename
.. option:: -a, --all-blocks
This option selects input description file generated by compiler while
instrumenting program.
Display all basic blocks. If there are multiple blocks for a single line of
source code, this option causes llvm-cov to show the count for each block
instead of just one count for the entire line.
.. option:: -gcda=filename
.. option:: -b, --branch-probabilities
This option selects coverage data file generated by instrumented compiler.
Display conditional branch probabilities and a summary of branch information.
.. option:: -dump
.. option:: -c, --branch-counts
This options enables output dump that is suitable for a developer to help
debug :program:`llvm-cov` itself.
Display branch counts instead of probabilities (requires -b).
.. option:: -f, --function-summaries
Show a summary of coverage for each function instead of just one summary for
an entire source file.
.. option:: --help
Display available options (--help-hidden for more).
.. option:: -l, --long-file-names
For coverage output of files included from the main source file, add the
main file name followed by ``##`` as a prefix to the output file names. This
can be combined with the --preserve-paths option to use complete paths for
both the main file and the included file.
.. option:: -n, --no-output
Do not output any ``.gcov`` files. Summary information is still
displayed.
.. option:: -o=<DIR|FILE>, --object-directory=<DIR>, --object-file=<FILE>
Find objects in DIR or based on FILE's path. If you specify a particular
object file, the coverage data files are expected to have the same base name
with ``.gcno`` and ``.gcda`` extensions. If you specify a directory, the
files are expected in that directory with the same base name as the source
file.
.. option:: -p, --preserve-paths
Preserve path components when naming the coverage output files. In addition
to the source file name, include the directories from the path to that
file. The directories are separate by ``#`` characters, with ``.`` directories
removed and ``..`` directories replaced by ``^`` characters. When used with
the --long-file-names option, this applies to both the main file name and the
included file name.
.. option:: -u, --unconditional-branches
Include unconditional branches in the output for the --branch-probabilities
option.
.. option:: -version
Display the version of llvm-cov.
EXIT STATUS
-----------

30
external/bsd/llvm/dist/llvm/docs/CommandGuide/llvm-dwarfdump.rst vendored Normal file
View File

@ -0,0 +1,30 @@
llvm-dwarfdump - print contents of DWARF sections
=================================================
SYNOPSIS
--------
:program:`llvm-dwarfdump` [*options*] [*filenames...*]
DESCRIPTION
-----------
:program:`llvm-dwarfdump` parses DWARF sections in the object files
and prints their contents in human-readable form.
OPTIONS
-------
.. option:: -debug-dump=section
Specify the DWARF section to dump.
For example, use ``abbrev`` to dump the contents of ``.debug_abbrev`` section,
``loc.dwo`` to dump the contents of ``.debug_loc.dwo`` etc.
See ``llvm-dwarfdump --help`` for the complete list of supported sections.
Use ``all`` to dump all DWARF sections. It is the default.
EXIT STATUS
-----------
:program:`llvm-dwarfdump` returns 0. Other exit codes imply internal
program error.

7
external/bsd/llvm/dist/llvm/docs/CommandGuide/llvm-symbolizer.rst vendored
View File

@ -61,11 +61,14 @@ OPTIONS
-------
.. option:: -obj
Path to object file to be symbolized.
.. option:: -functions
.. option:: -functions=[none|short|linkage]
Print function names as well as source file/line locations. Defaults to true.
Specify the way function names are printed (omit function name,
print short function name, or print full linkage name, respectively).
Defaults to ``linkage``.
.. option:: -use-symbol-table

3
external/bsd/llvm/dist/llvm/docs/CommandGuide/tblgen.rst vendored
View File

@ -15,7 +15,8 @@ users of LLVM will not need to use this program. It is only for assisting with
writing an LLVM target backend.
The input and output of :program:`tblgen` is beyond the scope of this short
introduction. Please see :doc:`../TableGenFundamentals`.
introduction; please see the :doc:`introduction to TableGen
<../TableGen/index>`.
The *filename* argument specifies the name of a Target Description (``.td``)
file to read as input.

6
external/bsd/llvm/dist/llvm/docs/CompilerWriterInfo.rst vendored
View File

@ -109,6 +109,12 @@ Other x86-specific information
* `Calling conventions for different C++ compilers and operating systems <http://www.agner.org/optimize/calling_conventions.pdf>`_
XCore
-----
* `The XMOS XS1 Architecture (ISA) <https://www.xmos.com/en/download/public/The-XMOS-XS1-Architecture%28X7879A%29.pdf>`_
* `Tools Development Guide (includes ABI) <https://www.xmos.com/download/public/Tools-Development-Guide%28X9114A%29.pdf>`_
Other relevant lists
--------------------

2
external/bsd/llvm/dist/llvm/docs/DeveloperPolicy.rst vendored
View File

@ -336,7 +336,7 @@ Making a Major Change
---------------------
When a developer begins a major new project with the aim of contributing it back
to LLVM, s/he should inform the community with an email to the `llvmdev
to LLVM, they should inform the community with an email to the `llvmdev
<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>`_ email list, to the extent
possible. The reason for this is to:

17
external/bsd/llvm/dist/llvm/docs/ExceptionHandling.rst vendored
View File

@ -327,10 +327,19 @@ This intrinsic returns the type info index in the exception table of the current
function. This value can be used to compare against the result of
``landingpad`` instruction. The single argument is a reference to a type info.
Uses of this intrinsic are generated by the C++ front-end.
SJLJ Intrinsics
---------------
The ``llvm.eh.sjlj`` intrinsics are used internally within LLVM's
backend. Uses of them are generated by the backend's
``SjLjEHPrepare`` pass.
.. _llvm.eh.sjlj.setjmp:
``llvm.eh.sjlj.setjmp``
-----------------------
~~~~~~~~~~~~~~~~~~~~~~~
.. code-block:: llvm
@ -352,7 +361,7 @@ available for use in a target-specific manner.
.. _llvm.eh.sjlj.longjmp:
``llvm.eh.sjlj.longjmp``
------------------------
~~~~~~~~~~~~~~~~~~~~~~~~
.. code-block:: llvm
@ -365,7 +374,7 @@ pointer are restored from the buffer, then control is transferred to the
destination address.
``llvm.eh.sjlj.lsda``
---------------------
~~~~~~~~~~~~~~~~~~~~~
.. code-block:: llvm
@ -377,7 +386,7 @@ function. The SJLJ front-end code stores this address in the exception handling
function context for use by the runtime.
``llvm.eh.sjlj.callsite``
-------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~
.. code-block:: llvm

31
external/bsd/llvm/dist/llvm/docs/Extensions.rst vendored
View File

@ -159,3 +159,34 @@ different COMDATs:
.globl Symbol2
Symbol2:
.long 1
Target Specific Behaviour
=========================
Windows on ARM
--------------
Stack Probe Emission
^^^^^^^^^^^^^^^^^^^^
The reference implementation (Microsoft Visual Studio 2012) emits stack probes
in the following fashion:
.. code-block:: gas
movw r4, #constant
bl __chkstk
sub.w sp, sp, r4
However, this has the limitation of 32 MiB (±16MiB). In order to accommodate
larger binaries, LLVM supports the use of ``-mcode-model=large`` to allow a 4GiB
range via a slight deviation. It will generate an indirect jump as follows:
.. code-block:: gas
movw r4, #constant
movw r12, :lower16:__chkstk
movt r12, :upper16:__chkstk
blx r12
sub.w sp, sp, r4

8
external/bsd/llvm/dist/llvm/docs/FAQ.rst vendored
View File

@ -184,14 +184,6 @@ This is `a bug in GCC <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13392>`_,
and affects projects other than LLVM. Try upgrading or downgrading your GCC.
Compiling LLVM with GCC succeeds, but the resulting tools do not work, what can be wrong?
-----------------------------------------------------------------------------------------
Several versions of GCC have shown a weakness in miscompiling the LLVM
codebase. Please consult your compiler version (``gcc --version``) to find
out whether it is `broken <GettingStarted.html#brokengcc>`_. If so, your only
option is to upgrade GCC to a known good version.
After Subversion update, rebuilding gives the error "No rule to make target".
-----------------------------------------------------------------------------
If the error is of the form:

3
external/bsd/llvm/dist/llvm/docs/GarbageCollection.rst vendored
View File

@ -500,8 +500,7 @@ This boilerplate collector does nothing. More specifically:
* The stack map is not compiled into the executable.
Using the LLVM makefiles (like the `sample project
<http://llvm.org/viewvc/llvm-project/llvm/trunk/projects/sample/>`__), this code
Using the LLVM makefiles, this code
can be compiled as a plugin using a simple makefile:
.. code-block:: make

22
external/bsd/llvm/dist/llvm/docs/GettingStarted.rst vendored
View File

@ -182,7 +182,7 @@ Package Version Notes
#. If you want to make changes to the configure scripts, you will need GNU
autoconf (2.60), and consequently, GNU M4 (version 1.4 or higher). You
will also need automake (1.9.6). We only use aclocal from that package.
#.Optional, adds compression / uncompression capabilities to selected LLVM
#. Optional, adds compression / uncompression capabilities to selected LLVM
tools.
Additionally, your compilation host is expected to have the usual plethora of
@ -561,8 +561,9 @@ Then, your .git/config should have [imap] sections.
pass = himitsu!
port = 993
sslverify = false
;
in English folder = "[Gmail]/Drafts"; example for Japanese, "Modified UTF-7" encoded.
; in English
folder = "[Gmail]/Drafts"
; example for Japanese, "Modified UTF-7" encoded.
folder = "[Gmail]/&Tgtm+DBN-"
; example for Traditional Chinese
folder = "[Gmail]/&g0l6Pw-"
@ -697,14 +698,12 @@ The following options can be used to set or enable LLVM specific options:
Controls which targets will be built and linked into llc. The default value
for ``target_options`` is "all" which builds and links all available targets.
The value "host-only" can be specified to build only a native compiler (no
cross-compiler targets available). The "native" target is selected as the
target of the build host. You can also specify a comma separated list of
target names that you want available in llc. The target names use all lower
case. The current set of targets is:
The "host" target is selected as the target of the build host. You can also
specify a comma separated list of target names that you want available in llc.
The target names use all lower case. The current set of targets is:
``arm, cpp, hexagon, mips, mipsel, msp430, powerpc, ptx, sparc, spu,
systemz, x86, x86_64, xcore``.
``aarch64, arm, arm64, cpp, hexagon, mips, mipsel, mips64, mips64el, msp430,
powerpc, nvptx, r600, sparc, systemz, x86, x86_64, xcore``.
``--enable-doxygen``
@ -1077,8 +1076,7 @@ different `tools`_.
This directory contains projects that are not strictly part of LLVM but are
shipped with LLVM. This is also the directory where you should create your own
LLVM-based projects. See ``llvm/projects/sample`` for an example of how to set
up your own project.
LLVM-based projects.
``llvm/runtime``
----------------

8
external/bsd/llvm/dist/llvm/docs/GettingStartedVS.rst vendored
View File

@ -34,7 +34,7 @@ Most of the tools build and work. ``bugpoint`` does build, but does
not work.
Additional information about the LLVM directory structure and tool chain
can be found on the main `Getting Started <GettingStarted.html>`_ page.
can be found on the main :doc:`GettingStarted` page.
Requirements
@ -97,7 +97,7 @@ Here's the short story for getting up and running quickly with LLVM:
using LLVM. Another important option is ``LLVM_TARGETS_TO_BUILD``,
which controls the LLVM target architectures that are included on the
build.
* See the `LLVM CMake guide <CMake.html>`_ for detailed information about
* See the :doc:`LLVM CMake guide <CMake>` for detailed information about
how to configure the LLVM build.
6. Start Visual Studio
@ -215,8 +215,8 @@ An Example Using the LLVM Tool Chain
Common Problems
===============
If you are having problems building or using LLVM, or if you have any other
general questions about LLVM, please consult the `Frequently Asked Questions
<FAQ.html>`_ page.
general questions about LLVM, please consult the :doc:`Frequently Asked Questions
<FAQ>` page.
Links

1
external/bsd/llvm/dist/llvm/docs/HowToReleaseLLVM.rst vendored
View File

@ -361,6 +361,7 @@ Below are the rules regarding patching the release branch:
#. For dot releases all patches must mantain both API and ABI compatibility with
the previous major release. Only bugfixes will be accepted.
Release Final Tasks
-------------------

4
external/bsd/llvm/dist/llvm/docs/HowToSetUpLLVMStyleRTTI.rst vendored
View File

@ -223,8 +223,8 @@ steps:
[...]
template <class T>
static bool classof(const T *,
::llvm::enable_if_c<
::llvm::is_base_of<Foo, T>::value
::std::enable_if<
::std::is_base_of<Foo, T>::value
>::type* = 0) { return true; }
[...]
};

28
external/bsd/llvm/dist/llvm/docs/InAlloca.rst vendored
View File

@ -5,8 +5,6 @@ Design and Usage of the InAlloca Attribute
Introduction
============
.. Warning:: This feature is unstable and not fully implemented.
The :ref:`inalloca <attr_inalloca>` attribute is designed to allow
taking the address of an aggregate argument that is being passed by
value through memory. Primarily, this feature is required for
@ -31,41 +29,39 @@ Intended Usage
==============
The example below is the intended LLVM IR lowering for some C++ code
that passes a default-constructed ``Foo`` object to ``g`` in the 32-bit
Microsoft C++ ABI.
that passes two default-constructed ``Foo`` objects to ``g`` in the
32-bit Microsoft C++ ABI.
.. code-block:: c++
// Foo is non-trivial.
struct Foo { int a, b; Foo(); ~Foo(); Foo(const &Foo); };
struct Foo { int a, b; Foo(); ~Foo(); Foo(const Foo &); };
void g(Foo a, Foo b);
void f() {
f(1, Foo(), 3);
g(Foo(), Foo());
}
.. code-block:: llvm
%struct.Foo = type { i32, i32 }
%callframe.f = type { %struct.Foo, %struct.Foo }
declare void @Foo_ctor(%Foo* %this)
declare void @Foo_dtor(%Foo* %this)
declare void @g(%Foo* inalloca %memargs)
declare void @Foo_ctor(%struct.Foo* %this)
declare void @Foo_dtor(%struct.Foo* %this)
declare void @g(<{ %struct.Foo, %struct.Foo }>* inalloca %memargs)
define void @f() {
entry:
%base = call i8* @llvm.stacksave()
%memargs = alloca %callframe.f
%b = getelementptr %callframe.f*, i32 0
%a = getelementptr %callframe.f*, i32 1
%memargs = alloca <{ %struct.Foo, %struct.Foo }>
%b = getelementptr <{ %struct.Foo, %struct.Foo }>* %memargs, i32 1
call void @Foo_ctor(%struct.Foo* %b)
; If a's ctor throws, we must destruct b.
invoke void @Foo_ctor(%struct.Foo* %arg1)
%a = getelementptr <{ %struct.Foo, %struct.Foo }>* %memargs, i32 0
invoke void @Foo_ctor(%struct.Foo* %a)
to label %invoke.cont unwind %invoke.unwind
invoke.cont:
store i32 1, i32* %arg0
call void @g(%callframe.f* inalloca %memargs)
call void @g(<{ %struct.Foo, %struct.Foo }>* inalloca %memargs)
call void @llvm.stackrestore(i8* %base)
...

4
external/bsd/llvm/dist/llvm/docs/LLVMBuild.rst vendored
View File

@ -86,8 +86,8 @@ LLVM primarily uses the following types of components:
libraries that they build on top of.
- *Build Tools* - Build tools are applications which are designed to be run
as part of the build process (typically to generate other source files).
Currently, LLVM uses one main build tool called :doc:`TableGen
<TableGenFundamentals>` to generate a variety of source files.
Currently, LLVM uses one main build tool called :doc:`TableGen/index`
to generate a variety of source files.
- *Tools* - Command line applications which are built using the LLVM
component libraries. Most LLVM tools are small and are primarily
frontends to the library interfaces.

375
external/bsd/llvm/dist/llvm/docs/LangRef.rst vendored
View File

@ -197,16 +197,6 @@ linkage:
private to be renamed as necessary to avoid collisions. Because the
symbol is private to the module, all references can be updated. This
doesn't show up in any symbol table in the object file.
``linker_private``
Similar to ``private``, but the symbol is passed through the
assembler and evaluated by the linker. Unlike normal strong symbols,
they are removed by the linker from the final linked image
(executable or dynamic library).
``linker_private_weak``
Similar to "``linker_private``", but the symbol is weak. Note that
``linker_private_weak`` symbols are subject to coalescing by the
linker. The symbols are removed by the linker from the final linked
image (executable or dynamic library).
``internal``
Similar to private, but the value shows as a local symbol
(``STB_LOCAL`` in the case of ELF) in the object file. This
@ -450,7 +440,10 @@ styles:
defining module will bind to the local symbol. That is, the symbol
cannot be overridden by another module.
.. _namedtypes:
A symbol with ``internal`` or ``private`` linkage must have ``default``
visibility.
.. _dllstorageclass:
DLL Storage Classes
-------------------
@ -471,31 +464,52 @@ DLL storage class:
exists for defining a dll interface, the compiler, assembler and linker know
it is externally referenced and must refrain from deleting the symbol.
Named Types
-----------
.. _tls_model:
LLVM IR allows you to specify name aliases for certain types. This can
make it easier to read the IR and make the IR more condensed
(particularly when recursive types are involved). An example of a name
specification is:
Thread Local Storage Models
---------------------------
A variable may be defined as ``thread_local``, which means that it will
not be shared by threads (each thread will have a separated copy of the
variable). Not all targets support thread-local variables. Optionally, a
TLS model may be specified:
``localdynamic``
For variables that are only used within the current shared library.
``initialexec``
For variables in modules that will not be loaded dynamically.
``localexec``
For variables defined in the executable and only used within it.
If no explicit model is given, the "general dynamic" model is used.
The models correspond to the ELF TLS models; see `ELF Handling For
Thread-Local Storage <http://people.redhat.com/drepper/tls.pdf>`_ for
more information on under which circumstances the different models may
be used. The target may choose a different TLS model if the specified
model is not supported, or if a better choice of model can be made.
A model can also be specified in a alias, but then it only governs how
the alias is accessed. It will not have any effect in the aliasee.
.. _namedtypes:
Structure Types
---------------
LLVM IR allows you to specify both "identified" and "literal" :ref:`structure
types <t_struct>`. Literal types are uniqued structurally, but identified types
are never uniqued. An :ref:`opaque structural type <t_opaque>` can also be used
to forward declare a type which is not yet available.
An example of a identified structure specification is:
.. code-block:: llvm
%mytype = type { %mytype*, i32 }
You may give a name to any :ref:`type <typesystem>` except
":ref:`void <t_void>`". Type name aliases may be used anywhere a type is
expected with the syntax "%mytype".
Note that type names are aliases for the structural type that they
indicate, and that you can therefore specify multiple names for the same
type. This often leads to confusing behavior when dumping out a .ll
file. Since LLVM IR uses structural typing, the name is not part of the
type. When printing out LLVM IR, the printer will pick *one name* to
render all types of a particular shape. This means that if you have code
where two different source types end up having the same LLVM type, that
the dumper will sometimes print the "wrong" or unexpected type. This is
an important design point and isn't going to change.
Prior to the LLVM 3.0 release, identified types were structurally uniqued. Only
literal types are uniqued in recent versions of LLVM.
.. _globalvars:
@ -511,24 +525,6 @@ to be placed in, and may have an optional explicit alignment specified.
Global variables in other translation units can also be declared, in which
case they don't have an initializer.
A variable may be defined as ``thread_local``, which means that it will
not be shared by threads (each thread will have a separated copy of the
variable). Not all targets support thread-local variables. Optionally, a
TLS model may be specified:
``localdynamic``
For variables that are only used within the current shared library.
``initialexec``
For variables in modules that will not be loaded dynamically.
``localexec``
For variables defined in the executable and only used within it.
The models correspond to the ELF TLS models; see `ELF Handling For
Thread-Local Storage <http://people.redhat.com/drepper/tls.pdf>`_ for
more information on under which circumstances the different models may
be used. The target may choose a different TLS model if the specified
model is not supported, or if a better choice of model can be made.
A variable may be defined as a global ``constant``, which indicates that
the contents of the variable will **never** be modified (enabling better
optimization, allowing the global data to be placed in the read-only
@ -586,6 +582,9 @@ iteration.
Globals can also have a :ref:`DLL storage class <dllstorageclass>`.
Variables and aliasaes can have a
:ref:`Thread Local Storage Model <tls_model>`.
Syntax::
[@<GlobalVarName> =] [Linkage] [Visibility] [DLLStorageClass] [ThreadLocal]
@ -672,7 +671,7 @@ Syntax::
define [linkage] [visibility] [DLLStorageClass]
[cconv] [ret attrs]
<ResultType> @<FunctionName> ([argument list])
[fn Attrs] [section "name"] [align N]
[unnamed_addr] [fn Attrs] [section "name"] [align N]
[gc] [prefix Constant] { ... }
.. _langref_aliases:
@ -688,14 +687,22 @@ Aliases may have an optional :ref:`linkage type <linkage>`, an optional
Syntax::
@<Name> = [Visibility] [DLLStorageClass] alias [Linkage] <AliaseeTy> @<Aliasee>
@<Name> = [Visibility] [DLLStorageClass] [ThreadLocal] alias [Linkage] <AliaseeTy> @<Aliasee>
The linkage must be one of ``private``, ``linker_private``,
``linker_private_weak``, ``internal``, ``linkonce``, ``weak``,
The linkage must be one of ``private``, ``internal``, ``linkonce``, ``weak``,
``linkonce_odr``, ``weak_odr``, ``external``. Note that some system linkers
might not correctly handle dropping a weak symbol that is aliased by a non-weak
alias.
Alias that are not ``unnamed_addr`` are guaranteed to have the same address as
the aliasee.
The aliasee must be a definition.
Aliases are not allowed to point to aliases with linkages that can be
overridden. Since they are only a second name, the possibility of the
intermediate alias being overridden cannot be represented in an object file.
.. _namedmetadatastructure:
Named Metadata
@ -780,8 +787,6 @@ Currently, only the following parameter attributes are defined:
``inalloca``
.. Warning:: This feature is unstable and not fully implemented.
The ``inalloca`` argument attribute allows the caller to take the
address of outgoing stack arguments. An ``inalloca`` argument must
be a pointer to stack memory produced by an ``alloca`` instruction.
@ -815,6 +820,9 @@ Currently, only the following parameter attributes are defined:
not to trap and to be properly aligned. This may only be applied to
the first parameter. This is not a valid attribute for return
values.
.. _noalias:
``noalias``
This indicates that pointer values :ref:`based <pointeraliasing>` on
the argument or return value do not alias pointer values which are
@ -824,8 +832,8 @@ Currently, only the following parameter attributes are defined:
"irrelevant" to the ``noalias`` keyword for the arguments and return
value used in that call. The caller shares the responsibility with
the callee for ensuring that these requirements are met. For further
details, please see the discussion of the NoAlias response in `alias
analysis <AliasAnalysis.html#MustMayNo>`_.
details, please see the discussion of the NoAlias response in :ref:`alias
analysis <Must, May, or No>`.
Note that this definition of ``noalias`` is intentionally similar
to the definition of ``restrict`` in C99 for function arguments,
@ -854,6 +862,13 @@ Currently, only the following parameter attributes are defined:
operands for the :ref:`bitcast instruction <i_bitcast>`. This is not a
valid attribute for return values and can only be applied to one parameter.
``nonnull``
This indicates that the parameter or return pointer is not null. This
attribute may only be applied to pointer typed parameters. This is not
checked or enforced by LLVM, the caller must ensure that the pointer
passed in is non-null, or the callee must ensure that the returned pointer
is non-null.
.. _gc:
Garbage Collector Names
@ -1505,7 +1520,7 @@ Atomic Memory Ordering Constraints
Atomic instructions (:ref:`cmpxchg <i_cmpxchg>`,
:ref:`atomicrmw <i_atomicrmw>`, :ref:`fence <i_fence>`,
:ref:`atomic load <i_load>`, and :ref:`atomic store <i_store>`) take
an ordering parameter that determines which other atomic instructions on
ordering parameters that determine which other atomic instructions on
the same address they *synchronize with*. These semantics are borrowed
from Java and C++0x, but are somewhat more colloquial. If these
descriptions aren't precise enough, check those specs (see spec
@ -1752,14 +1767,12 @@ Floating Point Types
* - ``ppc_fp128``
- 128-bit floating point value (two 64-bits)
.. _t_x86mmx:
X86mmx Type
"""""""""""
X86_mmx Type
""""""""""""
:Overview:
The x86mmx type represents a value held in an MMX register on an x86
The x86_mmx type represents a value held in an MMX register on an x86
machine. The operations allowed on it are quite limited: parameters and
return values, load and store, and bitcast. User-specified MMX
instructions are represented as intrinsic or asm calls with arguments
@ -1770,7 +1783,7 @@ of this type.
::
x86mmx
x86_mmx
.. _t_pointer:
@ -2001,6 +2014,8 @@ notion of a forward declared structure.
| ``opaque`` | An opaque type. |
+--------------+-------------------+
.. _constants:
Constants
=========
@ -2055,7 +2070,7 @@ The IEEE 16-bit format (half precision) is represented by ``0xH``
followed by 4 hexadecimal digits. All hexadecimal formats are big-endian
(sign bit at the left).
There are no constants of type x86mmx.
There are no constants of type x86_mmx.
.. _complexconstants:
@ -2785,15 +2800,29 @@ for optimizations are prefixed with ``llvm.mem``.
'``llvm.mem.parallel_loop_access``' Metadata
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For a loop to be parallel, in addition to using
the ``llvm.loop`` metadata to mark the loop latch branch instruction,
also all of the memory accessing instructions in the loop body need to be
marked with the ``llvm.mem.parallel_loop_access`` metadata. If there
is at least one memory accessing instruction not marked with the metadata,
the loop must be considered a sequential loop. This causes parallel loops to be
converted to sequential loops due to optimization passes that are unaware of
the parallel semantics and that insert new memory instructions to the loop
body.
The ``llvm.mem.parallel_loop_access`` metadata refers to a loop identifier,
or metadata containing a list of loop identifiers for nested loops.
The metadata is attached to memory accessing instructions and denotes that
no loop carried memory dependence exist between it and other instructions denoted
with the same loop identifier.
Precisely, given two instructions ``m1`` and ``m2`` that both have the
``llvm.mem.parallel_loop_access`` metadata, with ``L1`` and ``L2`` being the
set of loops associated with that metadata, respectively, then there is no loop
carried dependence between ``m1`` and ``m2`` for loops ``L1`` or
``L2``.
As a special case, if all memory accessing instructions in a loop have
``llvm.mem.parallel_loop_access`` metadata that refers to that loop, then the
loop has no loop carried memory dependences and is considered to be a parallel
loop.
Note that if not all memory access instructions have such metadata referring to
the loop, then the loop is considered not being trivially parallel. Additional
memory dependence analysis is required to make that determination. As a fail
safe mechanism, this causes loops that were originally parallel to be considered
sequential (if optimization passes that are unaware of the parallel semantics
insert new memory instructions into the loop body).
Example of a loop that is considered parallel due to its correct use of
both ``llvm.loop`` and ``llvm.mem.parallel_loop_access``
@ -2803,9 +2832,9 @@ metadata types that refer to the same loop identifier metadata.
for.body:
...
%0 = load i32* %arrayidx, align 4, !llvm.mem.parallel_loop_access !0
%val0 = load i32* %arrayidx, !llvm.mem.parallel_loop_access !0
...
store i32 %0, i32* %arrayidx4, align 4, !llvm.mem.parallel_loop_access !0
store i32 %val0, i32* %arrayidx1, !llvm.mem.parallel_loop_access !0
...
br i1 %exitcond, label %for.end, label %for.body, !llvm.loop !0
@ -2820,21 +2849,22 @@ the loop identifier metadata node directly:
.. code-block:: llvm
outer.for.body:
...
...
%val1 = load i32* %arrayidx3, !llvm.mem.parallel_loop_access !2
...
br label %inner.for.body
inner.for.body:
...
%0 = load i32* %arrayidx, align 4, !llvm.mem.parallel_loop_access !0
%val0 = load i32* %arrayidx1, !llvm.mem.parallel_loop_access !0
...
store i32 %0, i32* %arrayidx4, align 4, !llvm.mem.parallel_loop_access !0
store i32 %val0, i32* %arrayidx2, !llvm.mem.parallel_loop_access !0
...
br i1 %exitcond, label %inner.for.end, label %inner.for.body, !llvm.loop !1
inner.for.end:
...
%0 = load i32* %arrayidx, align 4, !llvm.mem.parallel_loop_access !0
...
store i32 %0, i32* %arrayidx4, align 4, !llvm.mem.parallel_loop_access !0
store i32 %val1, i32* %arrayidx4, !llvm.mem.parallel_loop_access !2
...
br i1 %exitcond, label %outer.for.end, label %outer.for.body, !llvm.loop !2
@ -3158,14 +3188,18 @@ The '``llvm.global_ctors``' Global Variable
.. code-block:: llvm
%0 = type { i32, void ()* }
@llvm.global_ctors = appending global [1 x %0] [%0 { i32 65535, void ()* @ctor }]
%0 = type { i32, void ()*, i8* }
@llvm.global_ctors = appending global [1 x %0] [%0 { i32 65535, void ()* @ctor, i8* @data }]
The ``@llvm.global_ctors`` array contains a list of constructor
functions and associated priorities. The functions referenced by this
array will be called in ascending order of priority (i.e. lowest first)
when the module is loaded. The order of functions with the same priority
is not defined.
functions, priorities, and an optional associated global or function.
The functions referenced by this array will be called in ascending order
of priority (i.e. lowest first) when the module is loaded. The order of
functions with the same priority is not defined.
If the third field is present, non-null, and points to a global variable
or function, the initializer function will only run if the associated
data from the current module is not discarded.
.. _llvmglobaldtors:
@ -3174,14 +3208,18 @@ The '``llvm.global_dtors``' Global Variable
.. code-block:: llvm
%0 = type { i32, void ()* }
@llvm.global_dtors = appending global [1 x %0] [%0 { i32 65535, void ()* @dtor }]
%0 = type { i32, void ()*, i8* }
@llvm.global_dtors = appending global [1 x %0] [%0 { i32 65535, void ()* @dtor, i8* @data }]
The ``@llvm.global_dtors`` array contains a list of destructor functions
and associated priorities. The functions referenced by this array will
be called in descending order of priority (i.e. highest first) when the
module is loaded. The order of functions with the same priority is not
defined.
The ``@llvm.global_dtors`` array contains a list of destructor
functions, priorities, and an optional associated global or function.
The functions referenced by this array will be called in descending
order of priority (i.e. highest first) when the module is unloaded. The
order of functions with the same priority is not defined.
If the third field is present, non-null, and points to a global variable
or function, the destructor function will only run if the associated
data from the current module is not discarded.
Instruction Reference
=====================
@ -4479,7 +4517,7 @@ Syntax:
::
<result> = extractelement <n x <ty>> <val>, i32 <idx> ; yields <ty>
<result> = extractelement <n x <ty>> <val>, <ty2> <idx> ; yields <ty>
Overview:
"""""""""
@ -4493,7 +4531,7 @@ Arguments:
The first operand of an '``extractelement``' instruction is a value of
:ref:`vector <t_vector>` type. The second operand is an index indicating
the position from which to extract the element. The index may be a
variable.
variable of any integer type.
Semantics:
""""""""""
@ -4519,7 +4557,7 @@ Syntax:
::
<result> = insertelement <n x <ty>> <val>, <ty> <elt>, i32 <idx> ; yields <n x <ty>>
<result> = insertelement <n x <ty>> <val>, <ty> <elt>, <ty2> <idx> ; yields <n x <ty>>
Overview:
"""""""""
@ -4534,7 +4572,7 @@ The first operand of an '``insertelement``' instruction is a value of
:ref:`vector <t_vector>` type. The second operand is a scalar value whose
type must equal the element type of the first operand. The third operand
is an index indicating the position at which to insert the value. The
index may be a variable.
index may be a variable of any integer type.
Semantics:
""""""""""
@ -4723,7 +4761,7 @@ Syntax:
::
<result> = alloca <type>[, inalloca][, <ty> <NumElements>][, align <alignment>] ; yields {type*}:result
<result> = alloca [inalloca] <type> [, <ty> <NumElements>] [, align <alignment>] ; yields {type*}:result
Overview:
"""""""""
@ -5000,7 +5038,7 @@ Syntax:
::
cmpxchg [volatile] <ty>* <pointer>, <ty> <cmp>, <ty> <new> [singlethread] <ordering> ; yields {ty}
cmpxchg [volatile] <ty>* <pointer>, <ty> <cmp>, <ty> <new> [singlethread] <success ordering> <failure ordering> ; yields {ty}
Overview:
"""""""""
@ -5023,8 +5061,11 @@ type, and the type of '<pointer>' must be a pointer to that type. If the
to modify the number or order of execution of this ``cmpxchg`` with
other :ref:`volatile operations <volatile>`.
The :ref:`ordering <ordering>` argument specifies how this ``cmpxchg``
synchronizes with other atomic operations.
The success and failure :ref:`ordering <ordering>` arguments specify how this
``cmpxchg`` synchronizes with other atomic operations. The both ordering
parameters must be at least ``monotonic``, the ordering constraint on failure
must be no stronger than that on success, and the failure ordering cannot be
either ``release`` or ``acq_rel``.
The optional "``singlethread``" argument declares that the ``cmpxchg``
is only atomic with respect to code (usually signal handlers) running in
@ -5042,10 +5083,9 @@ operand is read and compared to '``<cmp>``'; if the read value is the
equal, '``<new>``' is written. The original value at the location is
returned.
A successful ``cmpxchg`` is a read-modify-write instruction for the purpose
of identifying release sequences. A failed ``cmpxchg`` is equivalent to an
atomic load with an ordering parameter determined by dropping any
``release`` part of the ``cmpxchg``'s ordering.
A successful ``cmpxchg`` is a read-modify-write instruction for the purpose of
identifying release sequences. A failed ``cmpxchg`` is equivalent to an atomic
load with an ordering parameter determined the second ordering parameter.
Example:
""""""""
@ -5059,7 +5099,7 @@ Example:
loop:
%cmp = phi i32 [ %orig, %entry ], [%old, %loop]
%squared = mul i32 %cmp, %cmp
%old = cmpxchg i32* %ptr, i32 %cmp, i32 %squared ; yields {i32}
%old = cmpxchg i32* %ptr, i32 %cmp, i32 %squared acq_rel monotonic ; yields {i32}
%success = icmp eq i32 %cmp, %old
br i1 %success, label %done, label %loop
@ -6130,7 +6170,7 @@ Overview:
"""""""""
The '``select``' instruction is used to choose one value based on a
condition, without branching.
condition, without IR-level branching.
Arguments:
""""""""""
@ -6168,7 +6208,7 @@ Syntax:
::
<result> = [tail] call [cconv] [ret attrs] <ty> [<fnty>*] <fnptrval>(<function args>) [fn attrs]
<result> = [tail | musttail] call [cconv] [ret attrs] <ty> [<fnty>*] <fnptrval>(<function args>) [fn attrs]
Overview:
"""""""""
@ -6180,17 +6220,34 @@ Arguments:
This instruction requires several arguments:
#. The optional "tail" marker indicates that the callee function does
not access any allocas or varargs in the caller. Note that calls may
be marked "tail" even if they do not occur before a
:ref:`ret <i_ret>` instruction. If the "tail" marker is present, the
function call is eligible for tail call optimization, but `might not
in fact be optimized into a jump <CodeGenerator.html#tailcallopt>`_.
The code generator may optimize calls marked "tail" with either 1)
automatic `sibling call
optimization <CodeGenerator.html#sibcallopt>`_ when the caller and
callee have matching signatures, or 2) forced tail call optimization
when the following extra requirements are met:
#. The optional ``tail`` and ``musttail`` markers indicate that the optimizers
should perform tail call optimization. The ``tail`` marker is a hint that
`can be ignored <CodeGenerator.html#sibcallopt>`_. The ``musttail`` marker
means that the call must be tail call optimized in order for the program to
be correct. The ``musttail`` marker provides these guarantees:
#. The call will not cause unbounded stack growth if it is part of a
recursive cycle in the call graph.
#. Arguments with the :ref:`inalloca <attr_inalloca>` attribute are
forwarded in place.
Both markers imply that the callee does not access allocas or varargs from
the caller. Calls marked ``musttail`` must obey the following additional
rules:
- The call must immediately precede a :ref:`ret <i_ret>` instruction,
or a pointer bitcast followed by a ret instruction.
- The ret instruction must return the (possibly bitcasted) value
produced by the call or void.
- The caller and callee prototypes must match. Pointer types of
parameters or return types may differ in pointee type, but not
in address space.
- The calling conventions of the caller and callee must match.
- All ABI-impacting function attributes, such as sret, byval, inreg,
returned, and inalloca, must match.
Tail call optimization for calls marked ``tail`` is guaranteed to occur if
the following conditions are met:
- Caller and callee both have the calling convention ``fastcc``.
- The call is in tail position (ret immediately follows call and ret
@ -6794,6 +6851,51 @@ Note that calling this intrinsic does not prevent function inlining or
other aggressive transformations, so the value returned may not be that
of the obvious source-language caller.
.. _int_read_register:
.. _int_write_register:
'``llvm.read_register``' and '``llvm.write_register``' Intrinsics
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Syntax:
"""""""
::
declare i32 @llvm.read_register.i32(metadata)
declare i64 @llvm.read_register.i64(metadata)
declare void @llvm.write_register.i32(metadata, i32 @value)
declare void @llvm.write_register.i64(metadata, i64 @value)
!0 = metadata !{metadata !"sp\00"}
Overview:
"""""""""
The '``llvm.read_register``' and '``llvm.write_register``' intrinsics
provides access to the named register. The register must be valid on
the architecture being compiled to. The type needs to be compatible
with the register being read.
Semantics:
""""""""""
The '``llvm.read_register``' intrinsic returns the current value of the
register, where possible. The '``llvm.write_register``' intrinsic sets
the current value of the register, where possible.
This is useful to implement named register global variables that need
to always be mapped to a specific register, as is common practice on
bare-metal programs including OS kernels.
The compiler doesn't check for register availability or use of the used
register in surrounding code, including inline assembly. Because of that,
allocatable registers are not supported.
Warning: So far it only works with the stack pointer on selected
architectures (ARM, AArch64, PowerPC and x86_64). Significant amount of
work is needed to support other registers and even more so, allocatable
registers.
.. _int_stacksave:
'``llvm.stacksave``' Intrinsic
@ -6953,6 +7055,39 @@ is lowered to a constant 0.
Note that runtime support may be conditional on the privilege-level code is
running at and the host platform.
'``llvm.clear_cache``' Intrinsic
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Syntax:
"""""""
::
declare void @llvm.clear_cache(i8*, i8*)
Overview:
"""""""""
The '``llvm.clear_cache``' intrinsic ensures visibility of modifications
in the specified range to the execution unit of the processor. On
targets with non-unified instruction and data cache, the implementation
flushes the instruction cache.
Semantics:
""""""""""
On platforms with coherent instruction and data caches (e.g. x86), this
intrinsic is a nop. On platforms with non-coherent instruction and data
cache (e.g. ARM, MIPS), the intrinsic is lowered either to appropriate
instructions or a system call, if cache flushing requires special
privileges.
The default behavior is to emit a call to ``__clear_cache`` from the run
time library.
This instrinsic does *not* empty the instruction pipeline. Modifications
of the current function are outside the scope of the intrinsic.
Standard C Library Intrinsics
-----------------------------

4
external/bsd/llvm/dist/llvm/docs/MakefileGuide.rst vendored
View File

@ -47,9 +47,7 @@ quickly by utilizing the built-in features that are used to compile LLVM. LLVM
compiles itself using the same features of the makefile system as used for
projects.
For complete details on setting up your projects configuration, simply mimic the
``llvm/projects/sample`` project. Or for further details, consult the
`Projects <Projects.html>`_ page.
For further details, consult the `Projects <Projects.html>`_ page.
Variable Values
---------------

59
external/bsd/llvm/dist/llvm/docs/Passes.rst vendored
View File

@ -302,15 +302,6 @@ standard error in a human-readable form.
This pass, only available in ``opt``, printsthe SCCs of each function CFG to
standard error in a human-readable fom.
``-print-dbginfo``: Print debug info in human readable form
-----------------------------------------------------------
Pass that prints instructions, and associated debug info:
#. source/line/col information
#. original variable name
#. original type name
``-print-dom-info``: Dominator Info Printer
-------------------------------------------
@ -549,6 +540,8 @@ instructions that are obviously dead.
A trivial dead store elimination that only considers basic-block local
redundant stores.
.. _passes-functionattrs:
``-functionattrs``: Deduce function attributes
----------------------------------------------
@ -657,7 +650,7 @@ program, and is used for a wide variety of program transformations.
------------------------------------------------
Combine instructions to form fewer, simple instructions. This pass does not
modify the CFG This pass is where algebraic simplification happens.
modify the CFG. This pass is where algebraic simplification happens.
This pass combines things like:
@ -690,6 +683,13 @@ program:
shifts.
#. … etc.
This pass can also simplify calls to specific well-known function calls (e.g.
runtime library functions). For example, a call ``exit(3)`` that occurs within
the ``main()`` function can be transformed into simply ``return 3``. Whether or
not library calls are simplified is controlled by the
:ref:`-functionattrs <passes-functionattrs>` pass and LLVM's knowledge of
library calls on different targets.
``-internalize``: Internalize Global Symbols
--------------------------------------------
@ -893,33 +893,14 @@ this would require knowledge of the entire call graph of the program including
any libraries which may not be available in bitcode form); it simply lowers
every atomic intrinsic.
``-lowerinvoke``: Lower invoke and unwind, for unwindless code generators
-------------------------------------------------------------------------
``-lowerinvoke``: Lower invokes to calls, for unwindless code generators
------------------------------------------------------------------------
This transformation is designed for use by code generators which do not yet
support stack unwinding. This pass supports two models of exception handling
lowering, the "cheap" support and the "expensive" support.
"Cheap" exception handling support gives the program the ability to execute any
program which does not "throw an exception", by turning "``invoke``"
instructions into calls and by turning "``unwind``" instructions into calls to
``abort()``. If the program does dynamically use the "``unwind``" instruction,
the program will print a message then abort.
"Expensive" exception handling support gives the full exception handling
support to the program at the cost of making the "``invoke``" instruction
really expensive. It basically inserts ``setjmp``/``longjmp`` calls to emulate
the exception handling as necessary.
Because the "expensive" support slows down programs a lot, and EH is only used
for a subset of the programs, it must be specifically enabled by the
``-enable-correct-eh-support`` option.
Note that after this pass runs the CFG is not entirely accurate (exceptional
control flow edges are not correct anymore) so only very simple things should
be done after the ``lowerinvoke`` pass has run (like generation of native
code). This should not be used as a general purpose "my LLVM-to-LLVM pass
doesn't support the ``invoke`` instruction yet" lowering pass.
support stack unwinding. This pass converts ``invoke`` instructions to
``call`` instructions, so that any exception-handling ``landingpad`` blocks
become dead code (which can be removed by running the ``-simplifycfg`` pass
afterwards).
``-lowerswitch``: Lower ``SwitchInst``\ s to branches
-----------------------------------------------------
@ -1039,14 +1020,6 @@ as:
Note that this pass has a habit of making definitions be dead. It is a good
idea to run a :ref:`DCE <passes-dce>` pass sometime after running this pass.
``-simplify-libcalls``: Simplify well-known library calls
---------------------------------------------------------
Applies a variety of small optimizations for calls to specific well-known
function calls (e.g. runtime library functions). For example, a call
``exit(3)`` that occurs within the ``main()`` function can be transformed into
simply ``return 3``.
.. _passes-simplifycfg:
``-simplifycfg``: Simplify the CFG

16
external/bsd/llvm/dist/llvm/docs/Phabricator.rst vendored
View File

@ -12,13 +12,6 @@ you can now submit your patches for Clang and LLVM at
Sign up
-------
There are two options to get an account on Phabricator. You can sign up
immediately with one of the supported OAuth account types if you're comfortable
with OAuth, but you can also email chandlerc@gmail.com to request an account to
be created manually without using OAuth. We're working to get support in
Phabricator to directly create new accounts, but currently this is a manual
process.
Note that if you use your Subversion user name as Phabricator user name,
Phabricator will automatically connect your submits to your Phabricator user in
the `Code Repository Browser`_.
@ -106,7 +99,7 @@ line:
Differential Revision: <URL>
where ``<URL>`` is the URL for the code review, starting with
``http://llvm-reviews.chandlerc.com/``.
``http://reviews.llvm.org/``.
Note that Arcanist will add this automatically.
@ -117,10 +110,9 @@ review, and add a link from the review to the commit.
Status
------
Currently, we're testing Phabricator for use with Clang/LLVM. Please let us
know whether you like it and what could be improved!
Please let us know whether you like it and what could be improved!
.. _LLVM's Phabricator: http://llvm-reviews.chandlerc.com
.. _Code Repository Browser: http://llvm-reviews.chandlerc.com/diffusion/
.. _LLVM's Phabricator: http://reviews.llvm.org
.. _Code Repository Browser: http://reviews.llvm.org/diffusion/
.. _Arcanist Quick Start: http://www.phabricator.com/docs/phabricator/article/Arcanist_Quick_Start.html
.. _Arcanist User Guide: http://www.phabricator.com/docs/phabricator/article/Arcanist_User_Guide.html

96
external/bsd/llvm/dist/llvm/docs/ProgrammersManual.rst vendored
View File

@ -263,6 +263,78 @@ almost never be stored or mentioned directly. They are intended solely for use
when defining a function which should be able to efficiently accept concatenated
strings.
.. _function_apis:
Passing functions and other callable objects
--------------------------------------------
Sometimes you may want a function to be passed a callback object. In order to
support lambda expressions and other function objects, you should not use the
traditional C approach of taking a function pointer and an opaque cookie:
.. code-block:: c++
void takeCallback(bool (*Callback)(Function *, void *), void *Cookie);
Instead, use one of the following approaches:
Function template
^^^^^^^^^^^^^^^^^
If you don't mind putting the definition of your function into a header file,
make it a function template that is templated on the callable type.
.. code-block:: c++
template<typename Callable>
void takeCallback(Callable Callback) {
Callback(1, 2, 3);
}
The ``function_ref`` class template
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The ``function_ref``
(`doxygen <http://llvm.org/doxygen/classllvm_1_1function_ref.html>`__) class
template represents a reference to a callable object, templated over the type
of the callable. This is a good choice for passing a callback to a function,
if you don't need to hold onto the callback after the function returns.
``function_ref<Ret(Param1, Param2, ...)>`` can be implicitly constructed from
any callable object that can be called with arguments of type ``Param1``,
``Param2``, ..., and returns a value that can be converted to type ``Ret``.
For example:
.. code-block:: c++
void visitBasicBlocks(Function *F, function_ref<bool (BasicBlock*)> Callback) {
for (BasicBlock &BB : *F)
if (Callback(&BB))
return;
}
can be called using:
.. code-block:: c++
visitBasicBlocks(F, [&](BasicBlock *BB) {
if (process(BB))
return isEmpty(BB);
return false;
});
Note that a ``function_ref`` object contains pointers to external memory, so
it is not generally safe to store an instance of the class (unless you know
that the external storage will not be freed).
``function_ref`` is small enough that it should always be passed by value.
``std::function``
^^^^^^^^^^^^^^^^^
You cannot use ``std::function`` within LLVM code, because it is not supported
by all our target toolchains.
.. _DEBUG:
The ``DEBUG()`` macro and ``-debug`` option
@ -475,8 +547,8 @@ these functions in your code in places you want to debug.
Getting this to work requires a small amount of configuration. On Unix systems
with X11, install the `graphviz <http://www.graphviz.org>`_ toolkit, and make
sure 'dot' and 'gv' are in your path. If you are running on Mac OS/X, download
and install the Mac OS/X `Graphviz program
sure 'dot' and 'gv' are in your path. If you are running on Mac OS X, download
and install the Mac OS X `Graphviz program
<http://www.pixelglow.com/graphviz/>`_ and add
``/Applications/Graphviz.app/Contents/MacOS/`` (or wherever you install it) to
your path. Once in your system and path are set up, rerun the LLVM configure
@ -1318,7 +1390,7 @@ type used.
.. _dss_valuemap:
llvm/ADT/ValueMap.h
llvm/IR/ValueMap.h
^^^^^^^^^^^^^^^^^^^
ValueMap is a wrapper around a :ref:`DenseMap <dss_densemap>` mapping
@ -1559,14 +1631,14 @@ Iterating over the ``Instruction`` in a ``Function``
If you're finding that you commonly iterate over a ``Function``'s
``BasicBlock``\ s and then that ``BasicBlock``'s ``Instruction``\ s,
``InstIterator`` should be used instead. You'll need to include
``llvm/Support/InstIterator.h`` (`doxygen
<http://llvm.org/doxygen/InstIterator_8h-source.html>`__) and then instantiate
``llvm/IR/InstIterator.h`` (`doxygen
<http://llvm.org/doxygen/InstIterator_8h.html>`__) and then instantiate
``InstIterator``\ s explicitly in your code. Here's a small example that shows
how to dump all instructions in a function to the standard error stream:
.. code-block:: c++
#include "llvm/Support/InstIterator.h"
#include "llvm/IR/InstIterator.h"
// F is a pointer to a Function instance
for (inst_iterator I = inst_begin(F), E = inst_end(F); I != E; ++I)
@ -1738,16 +1810,12 @@ chain of ``F``:
Function *F = ...;
for (Value::use_iterator i = F->use_begin(), e = F->use_end(); i != e; ++i)
if (Instruction *Inst = dyn_cast<Instruction>(*i)) {
for (User *U : GV->users()) {
if (Instruction *Inst = dyn_cast<Instruction>(U)) {
errs() << "F is used in instruction:\n";
errs() << *Inst << "\n";
}
Note that dereferencing a ``Value::use_iterator`` is not a very cheap operation.
Instead of performing ``*i`` above several times, consider doing it only once in
the loop body and reusing its result.
Alternatively, it's common to have an instance of the ``User`` Class (`doxygen
<http://llvm.org/doxygen/classllvm_1_1User.html>`__) and need to know what
``Value``\ s are used by it. The list of all ``Value``\ s used by a ``User`` is
@ -1759,8 +1827,8 @@ instruction uses (that is, the operands of the particular ``Instruction``):
Instruction *pi = ...;
for (User::op_iterator i = pi->op_begin(), e = pi->op_end(); i != e; ++i) {
Value *v = *i;
for (Use &U : pi->operands()) {
Value *v = U.get();
// ...
}

74
external/bsd/llvm/dist/llvm/docs/Projects.rst vendored
View File

@ -37,82 +37,16 @@ There are two ways that you can set all of these variables:
of LLVM, and the ability to support multiple object directories from a single
source directory.
This document assumes that you will base your project on the LLVM sample project
found in ``llvm/projects/sample``. If you want to devise your own build system,
studying the sample project and LLVM ``Makefiles`` will probably provide enough
information on how to write your own ``Makefiles``.
Create a Project from the Sample Project
========================================
Follow these simple steps to start your project:
1. Copy the ``llvm/projects/sample`` directory to any place of your choosing.
You can place it anywhere you like. Rename the directory to match the name
of your project.
2. If you downloaded LLVM using Subversion, remove all the directories named
``.svn`` (and all the files therein) from your project's new source tree.
This will keep Subversion from thinking that your project is inside
``llvm/trunk/projects/sample``.
3. Add your source code and Makefiles to your source tree.
4. If you want your project to be configured with the ``configure`` script then
you need to edit ``autoconf/configure.ac`` as follows:
* **AC_INIT** - Place the name of your project, its version number and a
contact email address for your project as the arguments to this macro
* **AC_CONFIG_AUX_DIR** - If your project isn't in the ``llvm/projects``
directory then you might need to adjust this so that it specifies a
relative path to the ``llvm/autoconf`` directory.
* **LLVM_CONFIG_PROJECT** - Just leave this alone.
* **AC_CONFIG_SRCDIR** - Specify a path to a file name that identifies your
project; or just leave it at ``Makefile.common.in``.
* **AC_CONFIG_FILES** - Do not change.
* **AC_CONFIG_MAKEFILE** - Use one of these macros for each Makefile that
your project uses. This macro arranges for your makefiles to be copied from
the source directory, unmodified, to the build directory.
5. After updating ``autoconf/configure.ac``, regenerate the configure script
with these commands. (You must be using ``Autoconf`` version 2.59 or later
and your ``aclocal`` version should be 1.9 or later.)
.. code-block:: bash
% cd autoconf
% ./AutoRegen.sh
6. Run ``configure`` in the directory in which you want to place object code.
Use the following options to tell your project where it can find LLVM:
``--with-llvmsrc=<directory>``
Tell your project where the LLVM source tree is located.
``--with-llvmobj=<directory>``
Tell your project where the LLVM object tree is located.
``--prefix=<directory>``
Tell your project where it should get installed.
That's it! Now all you have to do is type ``gmake`` (or ``make`` if you're on a
GNU/Linux system) in the root of your object directory, and your project should
build.
If you want to devise your own build system, studying other projects and LLVM
``Makefiles`` will probably provide enough information on how to write your own
``Makefiles``.
Source Tree Layout
==================
In order to use the LLVM build system, you will want to organize your source
code so that it can benefit from the build system's features. Mainly, you want
your source tree layout to look similar to the LLVM source tree layout. The
best way to do this is to just copy the project tree from
``llvm/projects/sample`` and modify it to meet your needs, but you can certainly
add to it if you want.
your source tree layout to look similar to the LLVM source tree layout.
Underneath your top level directory, you should have the following directories:

9
external/bsd/llvm/dist/llvm/docs/README.txt vendored
View File

@ -40,3 +40,12 @@ The correspondence between .rst files and man pages is
These .rst files are also included during HTML generation so they are also
viewable online (as noted above) at e.g.
`http://llvm.org/docs/CommandGuide/Foo.html`.
Checking links
==============
The reachibility of external links in the documentation can be checked by
running:
cd docs/
make -f Makefile.sphinx linkcheck

37
external/bsd/llvm/dist/llvm/docs/ReleaseNotes.rst vendored
View File

@ -37,9 +37,6 @@ Non-comprehensive list of changes in this release
* All backends have been changed to use the MC asm printer and support for the
non MC one has been removed.
* The ARM back-end now has the EHABI exception handling enabled by default. Use
`-arm-disable-ehabi` to turn it off (both landing pads and unwind tables).
* Clang can now successfully self-host itself on Linux/Sparc64 and on
FreeBSD/Sparc64.
@ -55,6 +52,9 @@ Non-comprehensive list of changes in this release
* llvm-ar now handles IR files like regular object files. In particular, a
regular symbol table is created for symbols defined in IR files.
* LLVM now always uses cfi directives for producing most stack
unwinding information.
.. NOTE
For small 1-3 sentence descriptions, just add an entry at the end of
this list. If your description won't fit comfortably in one bullet
@ -74,6 +74,37 @@ Non-comprehensive list of changes in this release
Makes programs 10x faster by doing Special New Thing.
Changes to the ARM Backend
--------------------------
Since release 3.3, a lot of new features have been included in the ARM
back-end but weren't production ready (ie. well tested) on release 3.4.
Just after the 3.4 release, we started heavily testing two major parts
of the back-end: the integrated assembler (IAS) and the ARM exception
handling (EHABI), and now they are enabled by default on LLVM/Clang.
The IAS received a lot of GNU extensions and directives, as well as some
specific pre-UAL instructions. Not all remaining directives will be
implemented, as we made judgement calls on the need versus the complexity,
and have chosen simplicity and future compatibility where hard decisions
had to be made. The major difference is, as stated above, the IAS validates
all inline ASM, not just for object emission, and that cause trouble with
some uses of inline ASM as pre-processor magic.
So, while the IAS is good enough to compile large projects (including most
of the Linux kernel), there are a few things that we can't (and probably
won't) do. For those cases, please use ``-fno-integrated-as`` in Clang.
Exception handling is another big change. After extensive testing and
changes to cooperate with Dwarf unwinding, EHABI is enabled by default.
The options ``-arm-enable-ehabi`` and ``-arm-enable-ehabi-descriptors``,
which were used to enable EHABI in the previous releases, are removed now.
This means all ARM code will emit EH unwind tables, or CFI unwinding (for
debug/profiling), or both. To avoid run-time inconsistencies, C code will
also emit EH tables (in case they interoperate with C++ code), as is the
case for other architectures (ex. x86_64).
External Open Source Projects Using LLVM 3.5
============================================

5
external/bsd/llvm/dist/llvm/docs/SegmentedStacks.rst vendored
View File

@ -13,9 +13,8 @@ monolithic chunk (of some worst case size) at thread initialization. This is
done by allocating stack blocks (henceforth called *stacklets*) and linking them
into a doubly linked list. The function prologue is responsible for checking if
the current stacklet has enough space for the function to execute; and if not,
call into the libgcc runtime to allocate more stack space. When using ``llc``,
segmented stacks can be enabled by adding ``-segmented-stacks`` to the command
line.
call into the libgcc runtime to allocate more stack space. Segmented stacks are
enabled with the ``"split-stack"`` attribute on LLVM functions.
The runtime functionality is `already there in libgcc
<http://gcc.gnu.org/wiki/SplitStacks>`_.

9
external/bsd/llvm/dist/llvm/docs/SourceLevelDebugging.rst vendored
View File

@ -319,6 +319,7 @@ Block descriptors
metadata,;; Reference to context descriptor
i32, ;; Line number
i32, ;; Column number
i32, ;; DWARF path discriminator value
i32 ;; Unique ID to identify blocks from a template function
}
@ -566,7 +567,7 @@ Local variables
metadata, ;; Reference to file where defined
i32, ;; 24 bit - Line number where defined
;; 8 bit - Argument number. 1 indicates 1st argument.
metadata, ;; Type descriptor
metadata, ;; Reference to the type descriptor
i32, ;; flags
metadata ;; (optional) Reference to inline location
}
@ -724,7 +725,8 @@ Compiled to LLVM, this function would be represented like this:
!15 = metadata !{i32 786688, metadata !16, metadata !"Z", metadata !5, i32 5,
metadata !11, i32 0, i32 0} ; [ DW_TAG_auto_variable ] [Z] \
[line 5]
!16 = metadata !{i32 786443, metadata !1, metadata !4, i32 4, i32 0, i32 0} \
!16 = metadata !{i32 786443, metadata !1, metadata !4, i32 4, i32 0, i32 0,
i32 0} \
; [ DW_TAG_lexical_block ] [/private/tmp/t.c]
!17 = metadata !{i32 5, i32 0, metadata !16, null}
!18 = metadata !{i32 6, i32 0, metadata !16, null}
@ -776,7 +778,8 @@ scope information for the variable ``Z``.
.. code-block:: llvm
!16 = metadata !{i32 786443, metadata !1, metadata !4, i32 4, i32 0, i32 0}
!16 = metadata !{i32 786443, metadata !1, metadata !4, i32 4, i32 0, i32 0,
i32 0}
; [ DW_TAG_lexical_block ] [/private/tmp/t.c]
!17 = metadata !{i32 5, i32 0, metadata !16, null}

31
external/bsd/llvm/dist/llvm/docs/StackMaps.rst vendored
View File

@ -313,17 +313,21 @@ format of this section follows:
.. code-block:: none
uint32 : Reserved (header)
uint32 : NumFunctions
StkSizeRecord[NumFunctions] {
uint32 : Function Offset
uint32 : Stack Size
Header {
uint8 : Stack Map Version (current version is 1)
uint8 : Reserved (expected to be 0)
uint16 : Reserved (expected to be 0)
}
uint32 : NumFunctions
uint32 : NumConstants
uint32 : NumRecords
StkSizeRecord[NumFunctions] {
uint64 : Function Address
uint64 : Stack Size
}
Constants[NumConstants] {
uint64 : LargeConstant
}
uint32 : NumRecords
StkMapRecord[NumRecords] {
uint64 : PatchPoint ID
uint32 : Instruction Offset
@ -335,12 +339,14 @@ format of this section follows:
uint16 : Dwarf RegNum
int32 : Offset or SmallConstant
}
uint16 : Padding
uint16 : NumLiveOuts
LiveOuts[NumLiveOuts]
uint16 : Dwarf RegNum
uint8 : Reserved
uint8 : Size in Bytes
}
uint32 : Padding (only if required to align to 8 byte)
}
The first byte of each location encodes a type that indicates how to
@ -394,6 +400,10 @@ immediately after compiling a module and encode the information in its
own format. Since the runtime controls the allocation of sections, it
can reuse the same stack map space for multiple modules.
Stackmap support is currently only implemented for 64-bit
platforms. However, a 32-bit implementation should be able to use the
same format with an insignificant amount of wasted space.
.. _stackmap-section:
Stack Map Section
@ -448,10 +458,11 @@ program could crash before the runtime could take back control.
To enforce these semantics, stackmap and patchpoint intrinsics are
considered to potentially read and write all memory. This may limit
optimization more than some clients desire. To address this problem
meta-data could be added to the intrinsic call to express aliasing,
thereby allowing optimizations to hoist certain loads above stack
maps.
optimization more than some clients desire. This limitation may be
avoided by marking the call site as "readonly". In the future we may
also allow meta-data to be added to the intrinsic call to express
aliasing, thereby allowing optimizations to hoist certain loads above
stack maps.
Direct Stack Map Entries
^^^^^^^^^^^^^^^^^^^^^^^^

428
external/bsd/llvm/dist/llvm/docs/TableGen/BackEnds.rst vendored Normal file
View File

@ -0,0 +1,428 @@
=================
TableGen BackEnds
=================
.. contents::
:local:
Introduction
============
TableGen backends are at the core of TableGen's functionality. The source files
provide the semantics to a generated (in memory) structure, but it's up to the
backend to print this out in a way that is meaningful to the user (normally a
C program including a file or a textual list of warnings, options and error
messages).
TableGen is used by both LLVM and Clang with very different goals. LLVM uses it
as a way to automate the generation of massive amounts of information regarding
instructions, schedules, cores and architecture features. Some backends generate
output that is consumed by more than one source file, so they need to be created
in a way that is easy to use pre-processor tricks. Some backends can also print
C code structures, so that they can be directly included as-is.
Clang, on the other hand, uses it mainly for diagnostic messages (errors,
warnings, tips) and attributes, so more on the textual end of the scale.
LLVM BackEnds
=============
.. warning::
This document is raw. Each section below needs three sub-sections: description
of its purpose with a list of users, output generated from generic input, and
finally why it needed a new backend (in case there's something similar).
Overall, each backend will take the same TableGen file type and transform into
similar output for different targets/uses. There is an implicit contract between
the TableGen files, the back-ends and their users.
For instance, a global contract is that each back-end produces macro-guarded
sections. Based on whether the file is included by a header or a source file,
or even in which context of each file the include is being used, you have
todefine a macro just before including it, to get the right output:
.. code-block:: c++
#define GET_REGINFO_TARGET_DESC
#include "ARMGenRegisterInfo.inc"
And just part of the generated file would be included. This is useful if
you need the same information in multiple formats (instantiation, initialization,
getter/setter functions, etc) from the same source TableGen file without having
to re-compile the TableGen file multiple times.
Sometimes, multiple macros might be defined before the same include file to
output multiple blocks:
.. code-block:: c++
#define GET_REGISTER_MATCHER
#define GET_SUBTARGET_FEATURE_NAME
#define GET_MATCHER_IMPLEMENTATION
#include "ARMGenAsmMatcher.inc"
The macros will be undef'd automatically as they're used, in the include file.
On all LLVM back-ends, the ``llvm-tblgen`` binary will be executed on the root
TableGen file ``<Target>.td``, which should include all others. This guarantees
that all information needed is accessible, and that no duplication is needed
in the TbleGen files.
CodeEmitter
-----------
**Purpose**: CodeEmitterGen uses the descriptions of instructions and their fields to
construct an automated code emitter: a function that, given a MachineInstr,
returns the (currently, 32-bit unsigned) value of the instruction.
**Output**: C++ code, implementing the target's CodeEmitter
class by overriding the virtual functions as ``<Target>CodeEmitter::function()``.
**Usage**: Used to include directly at the end of ``<Target>CodeEmitter.cpp``, and
with option `-mc-emitter` to be included in ``<Target>MCCodeEmitter.cpp``.
RegisterInfo
------------
**Purpose**: This tablegen backend is responsible for emitting a description of a target
register file for a code generator. It uses instances of the Register,
RegisterAliases, and RegisterClass classes to gather this information.
**Output**: C++ code with enums and structures representing the register mappings,
properties, masks, etc.
**Usage**: Both on ``<Target>BaseRegisterInfo`` and ``<Target>MCTargetDesc`` (headers
and source files) with macros defining in which they are for declaration vs.
initialization issues.
InstrInfo
---------
**Purpose**: This tablegen backend is responsible for emitting a description of the target
instruction set for the code generator. (what are the differences from CodeEmitter?)
**Output**: C++ code with enums and structures representing the register mappings,
properties, masks, etc.
**Usage**: Both on ``<Target>BaseInstrInfo`` and ``<Target>MCTargetDesc`` (headers
and source files) with macros defining in which they are for declaration vs.
AsmWriter
---------
**Purpose**: Emits an assembly printer for the current target.
**Output**: Implementation of ``<Target>InstPrinter::printInstruction()``, among
other things.
**Usage**: Included directly into ``InstPrinter/<Target>InstPrinter.cpp``.
AsmMatcher
----------
**Purpose**: Emits a target specifier matcher for
converting parsed assembly operands in the MCInst structures. It also
emits a matcher for custom operand parsing. Extensive documentation is
written on the ``AsmMatcherEmitter.cpp`` file.
**Output**: Assembler parsers' matcher functions, declarations, etc.
**Usage**: Used in back-ends' ``AsmParser/<Target>AsmParser.cpp`` for
building the AsmParser class.
Disassembler
------------
**Purpose**: Contains disassembler table emitters for various
architectures. Extensive documentation is written on the
``DisassemblerEmitter.cpp`` file.
**Output**: Decoding tables, static decoding functions, etc.
**Usage**: Directly included in ``Disassembler/<Target>Disassembler.cpp``
to cater for all default decodings, after all hand-made ones.
PseudoLowering
--------------
**Purpose**: Generate pseudo instruction lowering.
**Output**: Implements ``ARMAsmPrinter::emitPseudoExpansionLowering()``.
**Usage**: Included directly into ``<Target>AsmPrinter.cpp``.
CallingConv
-----------
**Purpose**: Responsible for emitting descriptions of the calling
conventions supported by this target.
**Output**: Implement static functions to deal with calling conventions
chained by matching styles, returning false on no match.
**Usage**: Used in ISelLowering and FastIsel as function pointers to
implementation returned by a CC sellection function.
DAGISel
-------
**Purpose**: Generate a DAG instruction selector.
**Output**: Creates huge functions for automating DAG selection.
**Usage**: Included in ``<Target>ISelDAGToDAG.cpp`` inside the target's
implementation of ``SelectionDAGISel``.
DFAPacketizer
-------------
**Purpose**: This class parses the Schedule.td file and produces an API that
can be used to reason about whether an instruction can be added to a packet
on a VLIW architecture. The class internally generates a deterministic finite
automaton (DFA) that models all possible mappings of machine instructions
to functional units as instructions are added to a packet.
**Output**: Scheduling tables for GPU back-ends (Hexagon, AMD).
**Usage**: Included directly on ``<Target>InstrInfo.cpp``.
FastISel
--------
**Purpose**: This tablegen backend emits code for use by the "fast"
instruction selection algorithm. See the comments at the top of
lib/CodeGen/SelectionDAG/FastISel.cpp for background. This file
scans through the target's tablegen instruction-info files
and extracts instructions with obvious-looking patterns, and it emits
code to look up these instructions by type and operator.
**Output**: Generates ``Predicate`` and ``FastEmit`` methods.
**Usage**: Implements private methods of the targets' implementation
of ``FastISel`` class.
Subtarget
---------
**Purpose**: Generate subtarget enumerations.
**Output**: Enums, globals, local tables for sub-target information.
**Usage**: Populates ``<Target>Subtarget`` and
``MCTargetDesc/<Target>MCTargetDesc`` files (both headers and source).
Intrinsic
---------
**Purpose**: Generate (target) intrinsic information.
OptParserDefs
-------------
**Purpose**: Print enum values for a class.
CTags
-----
**Purpose**: This tablegen backend emits an index of definitions in ctags(1)
format. A helper script, utils/TableGen/tdtags, provides an easier-to-use
interface; run 'tdtags -H' for documentation.
Clang BackEnds
==============
ClangAttrClasses
----------------
**Purpose**: Creates Attrs.inc, which contains semantic attribute class
declarations for any attribute in ``Attr.td`` that has not set ``ASTNode = 0``.
This file is included as part of ``Attr.h``.
ClangAttrParserStringSwitches
-----------------------------
**Purpose**: Creates AttrParserStringSwitches.inc, which contains
StringSwitch::Case statements for parser-related string switches. Each switch
is given its own macro (such as ``CLANG_ATTR_ARG_CONTEXT_LIST``, or
``CLANG_ATTR_IDENTIFIER_ARG_LIST``), which is expected to be defined before
including AttrParserStringSwitches.inc, and undefined after.
ClangAttrImpl
-------------
**Purpose**: Creates AttrImpl.inc, which contains semantic attribute class
definitions for any attribute in ``Attr.td`` that has not set ``ASTNode = 0``.
This file is included as part of ``AttrImpl.cpp``.
ClangAttrList
-------------
**Purpose**: Creates AttrList.inc, which is used when a list of semantic
attribute identifiers is required. For instance, ``AttrKinds.h`` includes this
file to generate the list of ``attr::Kind`` enumeration values. This list is
separated out into multiple categories: attributes, inheritable attributes, and
inheritable parameter attributes. This categorization happens automatically
based on information in ``Attr.td`` and is used to implement the ``classof``
functionality required for ``dyn_cast`` and similar APIs.
ClangAttrPCHRead
----------------
**Purpose**: Creates AttrPCHRead.inc, which is used to deserialize attributes
in the ``ASTReader::ReadAttributes`` function.
ClangAttrPCHWrite
-----------------
**Purpose**: Creates AttrPCHWrite.inc, which is used to serialize attributes in
the ``ASTWriter::WriteAttributes`` function.
ClangAttrSpellings
---------------------
**Purpose**: Creates AttrSpellings.inc, which is used to implement the
``__has_attribute`` feature test macro.
ClangAttrSpellingListIndex
--------------------------
**Purpose**: Creates AttrSpellingListIndex.inc, which is used to map parsed
attribute spellings (including which syntax or scope was used) to an attribute
spelling list index. These spelling list index values are internal
implementation details exposed via
``AttributeList::getAttributeSpellingListIndex``.
ClangAttrVisitor
-------------------
**Purpose**: Creates AttrVisitor.inc, which is used when implementing
recursive AST visitors.
ClangAttrTemplateInstantiate
----------------------------
**Purpose**: Creates AttrTemplateInstantiate.inc, which implements the
``instantiateTemplateAttribute`` function, used when instantiating a template
that requires an attribute to be cloned.
ClangAttrParsedAttrList
-----------------------
**Purpose**: Creates AttrParsedAttrList.inc, which is used to generate the
``AttributeList::Kind`` parsed attribute enumeration.
ClangAttrParsedAttrImpl
-----------------------
**Purpose**: Creates AttrParsedAttrImpl.inc, which is used by
``AttributeList.cpp`` to implement several functions on the ``AttributeList``
class. This functionality is implemented via the ``AttrInfoMap ParsedAttrInfo``
array, which contains one element per parsed attribute object.
ClangAttrParsedAttrKinds
------------------------
**Purpose**: Creates AttrParsedAttrKinds.inc, which is used to implement the
``AttributeList::getKind`` function, mapping a string (and syntax) to a parsed
attribute ``AttributeList::Kind`` enumeration.
ClangAttrDump
-------------
**Purpose**: Creates AttrDump.inc, which dumps information about an attribute.
It is used to implement ``ASTDumper::dumpAttr``.
ClangDiagsDefs
--------------
Generate Clang diagnostics definitions.
ClangDiagGroups
---------------
Generate Clang diagnostic groups.
ClangDiagsIndexName
-------------------
Generate Clang diagnostic name index.
ClangCommentNodes
-----------------
Generate Clang AST comment nodes.
ClangDeclNodes
--------------
Generate Clang AST declaration nodes.
ClangStmtNodes
--------------
Generate Clang AST statement nodes.
ClangSACheckers
---------------
Generate Clang Static Analyzer checkers.
ClangCommentHTMLTags
--------------------
Generate efficient matchers for HTML tag names that are used in documentation comments.
ClangCommentHTMLTagsProperties
------------------------------
Generate efficient matchers for HTML tag properties.
ClangCommentHTMLNamedCharacterReferences
----------------------------------------
Generate function to translate named character references to UTF-8 sequences.
ClangCommentCommandInfo
-----------------------
Generate command properties for commands that are used in documentation comments.
ClangCommentCommandList
-----------------------
Generate list of commands that are used in documentation comments.
ArmNeon
-------
Generate arm_neon.h for clang.
ArmNeonSema
-----------
Generate ARM NEON sema support for clang.
ArmNeonTest
-----------
Generate ARM NEON tests for clang.
AttrDocs
--------
**Purpose**: Creates ``AttributeReference.rst`` from ``AttrDocs.td``, and is
used for documenting user-facing attributes.
How to write a back-end
=======================
TODO.
Until we get a step-by-step HowTo for writing TableGen backends, you can at
least grab the boilerplate (build system, new files, etc.) from Clang's
r173931.
TODO: How they work, how to write one. This section should not contain details
about any particular backend, except maybe ``-print-enums`` as an example. This
should highlight the APIs in ``TableGen/Record.h``.

31
external/bsd/llvm/dist/llvm/docs/TableGen/Deficiencies.rst vendored Normal file
View File

@ -0,0 +1,31 @@
=====================
TableGen Deficiencies
=====================
.. contents::
:local:
Introduction
============
Despite being very generic, TableGen has some deficiencies that have been
pointed out numerous times. The common theme is that, while TableGen allows
you to build Domain-Specific-Languages, the final languages that you create
lack the power of other DSLs, which in turn increase considerably the size
and complexity of TableGen files.
At the same time, TableGen allows you to create virtually any meaning of
the basic concepts via custom-made back-ends, which can pervert the original
design and make it very hard for newcomers to understand it.
There are some in favour of extending the semantics even more, but making sure
back-ends adhere to strict rules. Others suggesting we should move to more
powerful DSLs designed with specific purposes, or even re-using existing
DSLs.
Known Problems
==============
TODO: Add here frequently asked questions about why TableGen doesn't do
what you want, how it might, and how we could extend/restrict it to
be more use friendly.

609
external/bsd/llvm/dist/llvm/docs/TableGen/LangIntro.rst vendored Normal file
View File

@ -0,0 +1,609 @@
==============================
TableGen Language Introduction
==============================
.. contents::
:local:
.. warning::
This document is extremely rough. If you find something lacking, please
fix it, file a documentation bug, or ask about it on llvmdev.
Introduction
============
This document is not meant to be a normative spec about the TableGen language
in and of itself (i.e. how to understand a given construct in terms of how
it affects the final set of records represented by the TableGen file). For
the formal language specification, see :doc:`LangRef`.
TableGen syntax
===============
TableGen doesn't care about the meaning of data (that is up to the backend to
define), but it does care about syntax, and it enforces a simple type system.
This section describes the syntax and the constructs allowed in a TableGen file.
TableGen primitives
-------------------
TableGen comments
^^^^^^^^^^^^^^^^^
TableGen supports C++ style "``//``" comments, which run to the end of the
line, and it also supports **nestable** "``/* */``" comments.
.. _TableGen type:
The TableGen type system
^^^^^^^^^^^^^^^^^^^^^^^^
TableGen files are strongly typed, in a simple (but complete) type-system.
These types are used to perform automatic conversions, check for errors, and to
help interface designers constrain the input that they allow. Every `value
definition`_ is required to have an associated type.
TableGen supports a mixture of very low-level types (such as ``bit``) and very
high-level types (such as ``dag``). This flexibility is what allows it to
describe a wide range of information conveniently and compactly. The TableGen
types are:
``bit``
A 'bit' is a boolean value that can hold either 0 or 1.
``int``
The 'int' type represents a simple 32-bit integer value, such as 5.
``string``
The 'string' type represents an ordered sequence of characters of arbitrary
length.
``bits<n>``
A 'bits' type is an arbitrary, but fixed, size integer that is broken up
into individual bits. This type is useful because it can handle some bits
being defined while others are undefined.
``list<ty>``
This type represents a list whose elements are some other type. The
contained type is arbitrary: it can even be another list type.
Class type
Specifying a class name in a type context means that the defined value must
be a subclass of the specified class. This is useful in conjunction with
the ``list`` type, for example, to constrain the elements of the list to a
common base class (e.g., a ``list<Register>`` can only contain definitions
derived from the "``Register``" class).
``dag``
This type represents a nestable directed graph of elements.
To date, these types have been sufficient for describing things that TableGen
has been used for, but it is straight-forward to extend this list if needed.
.. _TableGen expressions:
TableGen values and expressions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TableGen allows for a pretty reasonable number of different expression forms
when building up values. These forms allow the TableGen file to be written in a
natural syntax and flavor for the application. The current expression forms
supported include:
``?``
uninitialized field
``0b1001011``
binary integer value
``07654321``
octal integer value (indicated by a leading 0)
``7``
decimal integer value
``0x7F``
hexadecimal integer value
``"foo"``
string value
``[{ ... }]``
usually called a "code fragment", but is just a multiline string literal
``[ X, Y, Z ]<type>``
list value. <type> is the type of the list element and is usually optional.
In rare cases, TableGen is unable to deduce the element type in which case
the user must specify it explicitly.
``{ a, b, c }``
initializer for a "bits<3>" value
``value``
value reference
``value{17}``
access to one bit of a value
``value{15-17}``
access to multiple bits of a value
``DEF``
reference to a record definition
``CLASS<val list>``
reference to a new anonymous definition of CLASS with the specified template
arguments.
``X.Y``
reference to the subfield of a value
``list[4-7,17,2-3]``
A slice of the 'list' list, including elements 4,5,6,7,17,2, and 3 from it.
Elements may be included multiple times.
``foreach <var> = [ <list> ] in { <body> }``
``foreach <var> = [ <list> ] in <def>``
Replicate <body> or <def>, replacing instances of <var> with each value
in <list>. <var> is scoped at the level of the ``foreach`` loop and must
not conflict with any other object introduced in <body> or <def>. Currently
only ``def``\s are expanded within <body>.
``foreach <var> = 0-15 in ...``
``foreach <var> = {0-15,32-47} in ...``
Loop over ranges of integers. The braces are required for multiple ranges.
``(DEF a, b)``
a dag value. The first element is required to be a record definition, the
remaining elements in the list may be arbitrary other values, including
nested ```dag``' values.
``!listconcat(a, b, ...)``
A list value that is the result of concatenating the 'a' and 'b' lists.
The lists must have the same element type.
More than two arguments are accepted with the result being the concatenation
of all the lists given.
``!strconcat(a, b, ...)``
A string value that is the result of concatenating the 'a' and 'b' strings.
More than two arguments are accepted with the result being the concatenation
of all the strings given.
``str1#str2``
"#" (paste) is a shorthand for !strconcat. It may concatenate things that
are not quoted strings, in which case an implicit !cast<string> is done on
the operand of the paste.
``!cast<type>(a)``
A symbol of type *type* obtained by looking up the string 'a' in the symbol
table. If the type of 'a' does not match *type*, TableGen aborts with an
error. !cast<string> is a special case in that the argument must be an
object defined by a 'def' construct.
``!subst(a, b, c)``
If 'a' and 'b' are of string type or are symbol references, substitute 'b'
for 'a' in 'c.' This operation is analogous to $(subst) in GNU make.
``!foreach(a, b, c)``
For each member 'b' of dag or list 'a' apply operator 'c.' 'b' is a dummy
variable that should be declared as a member variable of an instantiated
class. This operation is analogous to $(foreach) in GNU make.
``!head(a)``
The first element of list 'a.'
``!tail(a)``
The 2nd-N elements of list 'a.'
``!empty(a)``
An integer {0,1} indicating whether list 'a' is empty.
``!if(a,b,c)``
'b' if the result of 'int' or 'bit' operator 'a' is nonzero, 'c' otherwise.
``!eq(a,b)``
'bit 1' if string a is equal to string b, 0 otherwise. This only operates
on string, int and bit objects. Use !cast<string> to compare other types of
objects.
Note that all of the values have rules specifying how they convert to values
for different types. These rules allow you to assign a value like "``7``"
to a "``bits<4>``" value, for example.
Classes and definitions
-----------------------
As mentioned in the :doc:`introduction <index>`, classes and definitions (collectively known as
'records') in TableGen are the main high-level unit of information that TableGen
collects. Records are defined with a ``def`` or ``class`` keyword, the record
name, and an optional list of "`template arguments`_". If the record has
superclasses, they are specified as a comma separated list that starts with a
colon character ("``:``"). If `value definitions`_ or `let expressions`_ are
needed for the class, they are enclosed in curly braces ("``{}``"); otherwise,
the record ends with a semicolon.
Here is a simple TableGen file:
.. code-block:: llvm
class C { bit V = 1; }
def X : C;
def Y : C {
string Greeting = "hello";
}
This example defines two definitions, ``X`` and ``Y``, both of which derive from
the ``C`` class. Because of this, they both get the ``V`` bit value. The ``Y``
definition also gets the Greeting member as well.
In general, classes are useful for collecting together the commonality between a
group of records and isolating it in a single place. Also, classes permit the
specification of default values for their subclasses, allowing the subclasses to
override them as they wish.
.. _value definition:
.. _value definitions:
Value definitions
^^^^^^^^^^^^^^^^^
Value definitions define named entries in records. A value must be defined
before it can be referred to as the operand for another value definition or
before the value is reset with a `let expression`_. A value is defined by
specifying a `TableGen type`_ and a name. If an initial value is available, it
may be specified after the type with an equal sign. Value definitions require
terminating semicolons.
.. _let expression:
.. _let expressions:
.. _"let" expressions within a record:
'let' expressions
^^^^^^^^^^^^^^^^^
A record-level let expression is used to change the value of a value definition
in a record. This is primarily useful when a superclass defines a value that a
derived class or definition wants to override. Let expressions consist of the
'``let``' keyword followed by a value name, an equal sign ("``=``"), and a new
value. For example, a new class could be added to the example above, redefining
the ``V`` field for all of its subclasses:
.. code-block:: llvm
class D : C { let V = 0; }
def Z : D;
In this case, the ``Z`` definition will have a zero value for its ``V`` value,
despite the fact that it derives (indirectly) from the ``C`` class, because the
``D`` class overrode its value.
.. _template arguments:
Class template arguments
^^^^^^^^^^^^^^^^^^^^^^^^
TableGen permits the definition of parameterized classes as well as normal
concrete classes. Parameterized TableGen classes specify a list of variable
bindings (which may optionally have defaults) that are bound when used. Here is
a simple example:
.. code-block:: llvm
class FPFormat<bits<3> val> {
bits<3> Value = val;
}
def NotFP : FPFormat<0>;
def ZeroArgFP : FPFormat<1>;
def OneArgFP : FPFormat<2>;
def OneArgFPRW : FPFormat<3>;
def TwoArgFP : FPFormat<4>;
def CompareFP : FPFormat<5>;
def CondMovFP : FPFormat<6>;
def SpecialFP : FPFormat<7>;
In this case, template arguments are used as a space efficient way to specify a
list of "enumeration values", each with a "``Value``" field set to the specified
integer.
The more esoteric forms of `TableGen expressions`_ are useful in conjunction
with template arguments. As an example:
.. code-block:: llvm
class ModRefVal<bits<2> val> {
bits<2> Value = val;
}
def None : ModRefVal<0>;
def Mod : ModRefVal<1>;
def Ref : ModRefVal<2>;
def ModRef : ModRefVal<3>;
class Value<ModRefVal MR> {
// Decode some information into a more convenient format, while providing
// a nice interface to the user of the "Value" class.
bit isMod = MR.Value{0};
bit isRef = MR.Value{1};
// other stuff...
}
// Example uses
def bork : Value<Mod>;
def zork : Value<Ref>;
def hork : Value<ModRef>;
This is obviously a contrived example, but it shows how template arguments can
be used to decouple the interface provided to the user of the class from the
actual internal data representation expected by the class. In this case,
running ``llvm-tblgen`` on the example prints the following definitions:
.. code-block:: llvm
def bork { // Value
bit isMod = 1;
bit isRef = 0;
}
def hork { // Value
bit isMod = 1;
bit isRef = 1;
}
def zork { // Value
bit isMod = 0;
bit isRef = 1;
}
This shows that TableGen was able to dig into the argument and extract a piece
of information that was requested by the designer of the "Value" class. For
more realistic examples, please see existing users of TableGen, such as the X86
backend.
Multiclass definitions and instances
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
While classes with template arguments are a good way to factor commonality
between two instances of a definition, multiclasses allow a convenient notation
for defining multiple definitions at once (instances of implicitly constructed
classes). For example, consider an 3-address instruction set whose instructions
come in two forms: "``reg = reg op reg``" and "``reg = reg op imm``"
(e.g. SPARC). In this case, you'd like to specify in one place that this
commonality exists, then in a separate place indicate what all the ops are.
Here is an example TableGen fragment that shows this idea:
.. code-block:: llvm
def ops;
def GPR;
def Imm;
class inst<int opc, string asmstr, dag operandlist>;
multiclass ri_inst<int opc, string asmstr> {
def _rr : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
(ops GPR:$dst, GPR:$src1, GPR:$src2)>;
def _ri : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
(ops GPR:$dst, GPR:$src1, Imm:$src2)>;
}
// Instantiations of the ri_inst multiclass.
defm ADD : ri_inst<0b111, "add">;
defm SUB : ri_inst<0b101, "sub">;
defm MUL : ri_inst<0b100, "mul">;
...
The name of the resultant definitions has the multidef fragment names appended
to them, so this defines ``ADD_rr``, ``ADD_ri``, ``SUB_rr``, etc. A defm may
inherit from multiple multiclasses, instantiating definitions from each
multiclass. Using a multiclass this way is exactly equivalent to instantiating
the classes multiple times yourself, e.g. by writing:
.. code-block:: llvm
def ops;
def GPR;
def Imm;
class inst<int opc, string asmstr, dag operandlist>;
class rrinst<int opc, string asmstr>
: inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
(ops GPR:$dst, GPR:$src1, GPR:$src2)>;
class riinst<int opc, string asmstr>
: inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
(ops GPR:$dst, GPR:$src1, Imm:$src2)>;
// Instantiations of the ri_inst multiclass.
def ADD_rr : rrinst<0b111, "add">;
def ADD_ri : riinst<0b111, "add">;
def SUB_rr : rrinst<0b101, "sub">;
def SUB_ri : riinst<0b101, "sub">;
def MUL_rr : rrinst<0b100, "mul">;
def MUL_ri : riinst<0b100, "mul">;
...
A ``defm`` can also be used inside a multiclass providing several levels of
multiclass instantiations.
.. code-block:: llvm
class Instruction<bits<4> opc, string Name> {
bits<4> opcode = opc;
string name = Name;
}
multiclass basic_r<bits<4> opc> {
def rr : Instruction<opc, "rr">;
def rm : Instruction<opc, "rm">;
}
multiclass basic_s<bits<4> opc> {
defm SS : basic_r<opc>;
defm SD : basic_r<opc>;
def X : Instruction<opc, "x">;
}
multiclass basic_p<bits<4> opc> {
defm PS : basic_r<opc>;
defm PD : basic_r<opc>;
def Y : Instruction<opc, "y">;
}
defm ADD : basic_s<0xf>, basic_p<0xf>;
...
// Results
def ADDPDrm { ...
def ADDPDrr { ...
def ADDPSrm { ...
def ADDPSrr { ...
def ADDSDrm { ...
def ADDSDrr { ...
def ADDY { ...
def ADDX { ...
``defm`` declarations can inherit from classes too, the rule to follow is that
the class list must start after the last multiclass, and there must be at least
one multiclass before them.
.. code-block:: llvm
class XD { bits<4> Prefix = 11; }
class XS { bits<4> Prefix = 12; }
class I<bits<4> op> {
bits<4> opcode = op;
}
multiclass R {
def rr : I<4>;
def rm : I<2>;
}
multiclass Y {
defm SS : R, XD;
defm SD : R, XS;
}
defm Instr : Y;
// Results
def InstrSDrm {
bits<4> opcode = { 0, 0, 1, 0 };
bits<4> Prefix = { 1, 1, 0, 0 };
}
...
def InstrSSrr {
bits<4> opcode = { 0, 1, 0, 0 };
bits<4> Prefix = { 1, 0, 1, 1 };
}
File scope entities
-------------------
File inclusion
^^^^^^^^^^^^^^
TableGen supports the '``include``' token, which textually substitutes the
specified file in place of the include directive. The filename should be
specified as a double quoted string immediately after the '``include``' keyword.
Example:
.. code-block:: llvm
include "foo.td"
'let' expressions
^^^^^^^^^^^^^^^^^
"Let" expressions at file scope are similar to `"let" expressions within a
record`_, except they can specify a value binding for multiple records at a
time, and may be useful in certain other cases. File-scope let expressions are
really just another way that TableGen allows the end-user to factor out
commonality from the records.
File-scope "let" expressions take a comma-separated list of bindings to apply,
and one or more records to bind the values in. Here are some examples:
.. code-block:: llvm
let isTerminator = 1, isReturn = 1, isBarrier = 1, hasCtrlDep = 1 in
def RET : I<0xC3, RawFrm, (outs), (ins), "ret", [(X86retflag 0)]>;
let isCall = 1 in
// All calls clobber the non-callee saved registers...
let Defs = [EAX, ECX, EDX, FP0, FP1, FP2, FP3, FP4, FP5, FP6, ST0,
MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7,
XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, XMM7, EFLAGS] in {
def CALLpcrel32 : Ii32<0xE8, RawFrm, (outs), (ins i32imm:$dst,variable_ops),
"call\t${dst:call}", []>;
def CALL32r : I<0xFF, MRM2r, (outs), (ins GR32:$dst, variable_ops),
"call\t{*}$dst", [(X86call GR32:$dst)]>;
def CALL32m : I<0xFF, MRM2m, (outs), (ins i32mem:$dst, variable_ops),
"call\t{*}$dst", []>;
}
File-scope "let" expressions are often useful when a couple of definitions need
to be added to several records, and the records do not otherwise need to be
opened, as in the case with the ``CALL*`` instructions above.
It's also possible to use "let" expressions inside multiclasses, providing more
ways to factor out commonality from the records, specially if using several
levels of multiclass instantiations. This also avoids the need of using "let"
expressions within subsequent records inside a multiclass.
.. code-block:: llvm
multiclass basic_r<bits<4> opc> {
let Predicates = [HasSSE2] in {
def rr : Instruction<opc, "rr">;
def rm : Instruction<opc, "rm">;
}
let Predicates = [HasSSE3] in
def rx : Instruction<opc, "rx">;
}
multiclass basic_ss<bits<4> opc> {
let IsDouble = 0 in
defm SS : basic_r<opc>;
let IsDouble = 1 in
defm SD : basic_r<opc>;
}
defm ADD : basic_ss<0xf>;
Looping
^^^^^^^
TableGen supports the '``foreach``' block, which textually replicates the loop
body, substituting iterator values for iterator references in the body.
Example:
.. code-block:: llvm
foreach i = [0, 1, 2, 3] in {
def R#i : Register<...>;
def F#i : Register<...>;
}
This will create objects ``R0``, ``R1``, ``R2`` and ``R3``. ``foreach`` blocks
may be nested. If there is only one item in the body the braces may be
elided:
.. code-block:: llvm
foreach i = [0, 1, 2, 3] in
def R#i : Register<...>;
Code Generator backend info
===========================
Expressions used by code generator to describe instructions and isel patterns:
``(implicit a)``
an implicitly defined physical register. This tells the dag instruction
selection emitter the input pattern's extra definitions matches implicit
physical register definitions.

6
external/bsd/llvm/dist/llvm/docs/TableGen/LangRef.rst vendored
View File

@ -2,8 +2,6 @@
TableGen Language Reference
===========================
.. sectionauthor:: Sean Silva <silvas@purdue.edu>
.. contents::
:local:
@ -18,7 +16,7 @@ This document is meant to be a normative spec about the TableGen language
in and of itself (i.e. how to understand a given construct in terms of how
it affects the final set of records represented by the TableGen file). If
you are unsure if this document is really what you are looking for, please
read :doc:`/TableGenFundamentals` first.
read the :doc:`introduction to TableGen <index>` first.
Notation
========
@ -95,7 +93,7 @@ wide variety of meanings:
BangOperator: one of
:!eq !if !head !tail !con
:!add !shl !sra !srl
:!cast !empty !subst !foreach !strconcat
:!cast !empty !subst !foreach !listconcat !strconcat
Syntax
======

309
external/bsd/llvm/dist/llvm/docs/TableGen/index.rst vendored Normal file
View File

@ -0,0 +1,309 @@
========
TableGen
========
.. contents::
:local:
.. toctree::
:hidden:
BackEnds
LangRef
LangIntro
Deficiencies
Introduction
============
TableGen's purpose is to help a human develop and maintain records of
domain-specific information. Because there may be a large number of these
records, it is specifically designed to allow writing flexible descriptions and
for common features of these records to be factored out. This reduces the
amount of duplication in the description, reduces the chance of error, and makes
it easier to structure domain specific information.
The core part of TableGen parses a file, instantiates the declarations, and
hands the result off to a domain-specific `backend`_ for processing.
The current major users of TableGen are :doc:`../CodeGenerator`
and the
`Clang diagnostics and attributes <http://clang.llvm.org/docs/UsersManual.html#controlling-errors-and-warnings>`_.
Note that if you work on TableGen much, and use emacs or vim, that you can find
an emacs "TableGen mode" and a vim language file in the ``llvm/utils/emacs`` and
``llvm/utils/vim`` directories of your LLVM distribution, respectively.
.. _intro:
The TableGen program
====================
TableGen files are interpreted by the TableGen program: `llvm-tblgen` available
on your build directory under `bin`. It is not installed in the system (or where
your sysroot is set to), since it has no use beyond LLVM's build process.
Running TableGen
----------------
TableGen runs just like any other LLVM tool. The first (optional) argument
specifies the file to read. If a filename is not specified, ``llvm-tblgen``
reads from standard input.
To be useful, one of the `backends`_ must be used. These backends are
selectable on the command line (type '``llvm-tblgen -help``' for a list). For
example, to get a list of all of the definitions that subclass a particular type
(which can be useful for building up an enum list of these records), use the
``-print-enums`` option:
.. code-block:: bash
$ llvm-tblgen X86.td -print-enums -class=Register
AH, AL, AX, BH, BL, BP, BPL, BX, CH, CL, CX, DH, DI, DIL, DL, DX, EAX, EBP, EBX,
ECX, EDI, EDX, EFLAGS, EIP, ESI, ESP, FP0, FP1, FP2, FP3, FP4, FP5, FP6, IP,
MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7, R10, R10B, R10D, R10W, R11, R11B, R11D,
R11W, R12, R12B, R12D, R12W, R13, R13B, R13D, R13W, R14, R14B, R14D, R14W, R15,
R15B, R15D, R15W, R8, R8B, R8D, R8W, R9, R9B, R9D, R9W, RAX, RBP, RBX, RCX, RDI,
RDX, RIP, RSI, RSP, SI, SIL, SP, SPL, ST0, ST1, ST2, ST3, ST4, ST5, ST6, ST7,
XMM0, XMM1, XMM10, XMM11, XMM12, XMM13, XMM14, XMM15, XMM2, XMM3, XMM4, XMM5,
XMM6, XMM7, XMM8, XMM9,
$ llvm-tblgen X86.td -print-enums -class=Instruction
ABS_F, ABS_Fp32, ABS_Fp64, ABS_Fp80, ADC32mi, ADC32mi8, ADC32mr, ADC32ri,
ADC32ri8, ADC32rm, ADC32rr, ADC64mi32, ADC64mi8, ADC64mr, ADC64ri32, ADC64ri8,
ADC64rm, ADC64rr, ADD16mi, ADD16mi8, ADD16mr, ADD16ri, ADD16ri8, ADD16rm,
ADD16rr, ADD32mi, ADD32mi8, ADD32mr, ADD32ri, ADD32ri8, ADD32rm, ADD32rr,
ADD64mi32, ADD64mi8, ADD64mr, ADD64ri32, ...
The default backend prints out all of the records.
If you plan to use TableGen, you will most likely have to write a `backend`_
that extracts the information specific to what you need and formats it in the
appropriate way.
Example
-------
With no other arguments, `llvm-tblgen` parses the specified file and prints out all
of the classes, then all of the definitions. This is a good way to see what the
various definitions expand to fully. Running this on the ``X86.td`` file prints
this (at the time of this writing):
.. code-block:: llvm
...
def ADD32rr { // Instruction X86Inst I
string Namespace = "X86";
dag OutOperandList = (outs GR32:$dst);
dag InOperandList = (ins GR32:$src1, GR32:$src2);
string AsmString = "add{l}\t{$src2, $dst|$dst, $src2}";
list<dag> Pattern = [(set GR32:$dst, (add GR32:$src1, GR32:$src2))];
list<Register> Uses = [];
list<Register> Defs = [EFLAGS];
list<Predicate> Predicates = [];
int CodeSize = 3;
int AddedComplexity = 0;
bit isReturn = 0;
bit isBranch = 0;
bit isIndirectBranch = 0;
bit isBarrier = 0;
bit isCall = 0;
bit canFoldAsLoad = 0;
bit mayLoad = 0;
bit mayStore = 0;
bit isImplicitDef = 0;
bit isConvertibleToThreeAddress = 1;
bit isCommutable = 1;
bit isTerminator = 0;
bit isReMaterializable = 0;
bit isPredicable = 0;
bit hasDelaySlot = 0;
bit usesCustomInserter = 0;
bit hasCtrlDep = 0;
bit isNotDuplicable = 0;
bit hasSideEffects = 0;
bit neverHasSideEffects = 0;
InstrItinClass Itinerary = NoItinerary;
string Constraints = "";
string DisableEncoding = "";
bits<8> Opcode = { 0, 0, 0, 0, 0, 0, 0, 1 };
Format Form = MRMDestReg;
bits<6> FormBits = { 0, 0, 0, 0, 1, 1 };
ImmType ImmT = NoImm;
bits<3> ImmTypeBits = { 0, 0, 0 };
bit hasOpSizePrefix = 0;
bit hasAdSizePrefix = 0;
bits<4> Prefix = { 0, 0, 0, 0 };
bit hasREX_WPrefix = 0;
FPFormat FPForm = ?;
bits<3> FPFormBits = { 0, 0, 0 };
}
...
This definition corresponds to the 32-bit register-register ``add`` instruction
of the x86 architecture. ``def ADD32rr`` defines a record named
``ADD32rr``, and the comment at the end of the line indicates the superclasses
of the definition. The body of the record contains all of the data that
TableGen assembled for the record, indicating that the instruction is part of
the "X86" namespace, the pattern indicating how the instruction is selected by
the code generator, that it is a two-address instruction, has a particular
encoding, etc. The contents and semantics of the information in the record are
specific to the needs of the X86 backend, and are only shown as an example.
As you can see, a lot of information is needed for every instruction supported
by the code generator, and specifying it all manually would be unmaintainable,
prone to bugs, and tiring to do in the first place. Because we are using
TableGen, all of the information was derived from the following definition:
.. code-block:: llvm
let Defs = [EFLAGS],
isCommutable = 1, // X = ADD Y,Z --> X = ADD Z,Y
isConvertibleToThreeAddress = 1 in // Can transform into LEA.
def ADD32rr : I<0x01, MRMDestReg, (outs GR32:$dst),
(ins GR32:$src1, GR32:$src2),
"add{l}\t{$src2, $dst|$dst, $src2}",
[(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>;
This definition makes use of the custom class ``I`` (extended from the custom
class ``X86Inst``), which is defined in the X86-specific TableGen file, to
factor out the common features that instructions of its class share. A key
feature of TableGen is that it allows the end-user to define the abstractions
they prefer to use when describing their information.
Each ``def`` record has a special entry called "NAME". This is the name of the
record ("``ADD32rr``" above). In the general case ``def`` names can be formed
from various kinds of string processing expressions and ``NAME`` resolves to the
final value obtained after resolving all of those expressions. The user may
refer to ``NAME`` anywhere she desires to use the ultimate name of the ``def``.
``NAME`` should not be defined anywhere else in user code to avoid conflicts.
Syntax
======
TableGen has a syntax that is loosely based on C++ templates, with built-in
types and specification. In addition, TableGen's syntax introduces some
automation concepts like multiclass, foreach, let, etc.
Basic concepts
--------------
TableGen files consist of two key parts: 'classes' and 'definitions', both of
which are considered 'records'.
**TableGen records** have a unique name, a list of values, and a list of
superclasses. The list of values is the main data that TableGen builds for each
record; it is this that holds the domain specific information for the
application. The interpretation of this data is left to a specific `backend`_,
but the structure and format rules are taken care of and are fixed by
TableGen.
**TableGen definitions** are the concrete form of 'records'. These generally do
not have any undefined values, and are marked with the '``def``' keyword.
.. code-block:: llvm
def FeatureFPARMv8 : SubtargetFeature<"fp-armv8", "HasFPARMv8", "true",
"Enable ARMv8 FP">;
In this example, FeatureFPARMv8 is ``SubtargetFeature`` record initialised
with some values. The names of the classes are defined via the
keyword `class` either on the same file or some other included. Most target
TableGen files include the generic ones in ``include/llvm/Target``.
**TableGen classes** are abstract records that are used to build and describe
other records. These classes allow the end-user to build abstractions for
either the domain they are targeting (such as "Register", "RegisterClass", and
"Instruction" in the LLVM code generator) or for the implementor to help factor
out common properties of records (such as "FPInst", which is used to represent
floating point instructions in the X86 backend). TableGen keeps track of all of
the classes that are used to build up a definition, so the backend can find all
definitions of a particular class, such as "Instruction".
.. code-block:: llvm
class ProcNoItin<string Name, list<SubtargetFeature> Features>
: Processor<Name, NoItineraries, Features>;
Here, the class ProcNoItin, receiving parameters `Name` of type `string` and
a list of target features is specializing the class Processor by passing the
arguments down as well as hard-coding NoItineraries.
**TableGen multiclasses** are groups of abstract records that are instantiated
all at once. Each instantiation can result in multiple TableGen definitions.
If a multiclass inherits from another multiclass, the definitions in the
sub-multiclass become part of the current multiclass, as if they were declared
in the current multiclass.
.. code-block:: llvm
multiclass ro_signed_pats<string T, string Rm, dag Base, dag Offset, dag Extend,
dag address, ValueType sty> {
def : Pat<(i32 (!cast<SDNode>("sextload" # sty) address)),
(!cast<Instruction>("LDRS" # T # "w_" # Rm # "_RegOffset")
Base, Offset, Extend)>;
def : Pat<(i64 (!cast<SDNode>("sextload" # sty) address)),
(!cast<Instruction>("LDRS" # T # "x_" # Rm # "_RegOffset")
Base, Offset, Extend)>;
}
defm : ro_signed_pats<"B", Rm, Base, Offset, Extend,
!foreach(decls.pattern, address,
!subst(SHIFT, imm_eq0, decls.pattern)),
i8>;
See the :doc:`TableGen Language Introduction <LangIntro>` for more generic
information on the usage of the language, and the
:doc:`TableGen Language Reference <LangRef>` for more in-depth description
of the formal language specification.
.. _backend:
.. _backends:
TableGen backends
=================
TableGen files have no real meaning without a back-end. The default operation
of running ``llvm-tblgen`` is to print the information in a textual format, but
that's only useful for debugging of the TableGen files themselves. The power
in TableGen is, however, to interpret the source files into an internal
representation that can be generated into anything you want.
Current usage of TableGen is to create include huge files with tables that you
can either include directly (if the output is in the language you're coding),
or be used in pre-processing via macros surrounding the include of the file.
Direct output can be used if the back-end already prints a table in C format
or if the output is just a list of strings (for error and warning messages).
Pre-processed output should be used if the same information needs to be used
in different contexts (like Instruction names), so your back-end should print
a meta-information list that can be shaped into different compile-time formats.
See the `TableGen BackEnds <BackEnds.html>`_ for more information.
TableGen Deficiencies
=====================
Despite being very generic, TableGen has some deficiencies that have been
pointed out numerous times. The common theme is that, while TableGen allows
you to build Domain-Specific-Languages, the final languages that you create
lack the power of other DSLs, which in turn increase considerably the size
and complecity of TableGen files.
At the same time, TableGen allows you to create virtually any meaning of
the basic concepts via custom-made back-ends, which can pervert the original
design and make it very hard for newcomers to understand the evil TableGen
file.
There are some in favour of extending the semantics even more, but making sure
back-ends adhere to strict rules. Others are suggesting we should move to less,
more powerful DSLs designed with specific purposes, or even re-using existing
DSLs.
Either way, this is a discussion that will likely span across several years,
if not decades. You can read more in the `TableGen Deficiencies <Deficiencies.html>`_
document.

795
external/bsd/llvm/dist/llvm/docs/TableGenFundamentals.rst vendored
View File

@ -2,794 +2,9 @@
TableGen Fundamentals
=====================
.. contents::
:local:
Moved
=====
Introduction
============
TableGen's purpose is to help a human develop and maintain records of
domain-specific information. Because there may be a large number of these
records, it is specifically designed to allow writing flexible descriptions and
for common features of these records to be factored out. This reduces the
amount of duplication in the description, reduces the chance of error, and makes
it easier to structure domain specific information.
The core part of TableGen `parses a file`_, instantiates the declarations, and
hands the result off to a domain-specific `TableGen backend`_ for processing.
The current major user of TableGen is the `LLVM code
generator <CodeGenerator.html>`_.
Note that if you work on TableGen much, and use emacs or vim, that you can find
an emacs "TableGen mode" and a vim language file in the ``llvm/utils/emacs`` and
``llvm/utils/vim`` directories of your LLVM distribution, respectively.
.. _intro:
Basic concepts
--------------
TableGen files consist of two key parts: 'classes' and 'definitions', both of
which are considered 'records'.
**TableGen records** have a unique name, a list of values, and a list of
superclasses. The list of values is the main data that TableGen builds for each
record; it is this that holds the domain specific information for the
application. The interpretation of this data is left to a specific `TableGen
backend`_, but the structure and format rules are taken care of and are fixed by
TableGen.
**TableGen definitions** are the concrete form of 'records'. These generally do
not have any undefined values, and are marked with the '``def``' keyword.
**TableGen classes** are abstract records that are used to build and describe
other records. These 'classes' allow the end-user to build abstractions for
either the domain they are targeting (such as "Register", "RegisterClass", and
"Instruction" in the LLVM code generator) or for the implementor to help factor
out common properties of records (such as "FPInst", which is used to represent
floating point instructions in the X86 backend). TableGen keeps track of all of
the classes that are used to build up a definition, so the backend can find all
definitions of a particular class, such as "Instruction".
**TableGen multiclasses** are groups of abstract records that are instantiated
all at once. Each instantiation can result in multiple TableGen definitions.
If a multiclass inherits from another multiclass, the definitions in the
sub-multiclass become part of the current multiclass, as if they were declared
in the current multiclass.
.. _described above:
An example record
-----------------
With no other arguments, TableGen parses the specified file and prints out all
of the classes, then all of the definitions. This is a good way to see what the
various definitions expand to fully. Running this on the ``X86.td`` file prints
this (at the time of this writing):
.. code-block:: llvm
...
def ADD32rr { // Instruction X86Inst I
string Namespace = "X86";
dag OutOperandList = (outs GR32:$dst);
dag InOperandList = (ins GR32:$src1, GR32:$src2);
string AsmString = "add{l}\t{$src2, $dst|$dst, $src2}";
list<dag> Pattern = [(set GR32:$dst, (add GR32:$src1, GR32:$src2))];
list<Register> Uses = [];
list<Register> Defs = [EFLAGS];
list<Predicate> Predicates = [];
int CodeSize = 3;
int AddedComplexity = 0;
bit isReturn = 0;
bit isBranch = 0;
bit isIndirectBranch = 0;
bit isBarrier = 0;
bit isCall = 0;
bit canFoldAsLoad = 0;
bit mayLoad = 0;
bit mayStore = 0;
bit isImplicitDef = 0;
bit isConvertibleToThreeAddress = 1;
bit isCommutable = 1;
bit isTerminator = 0;
bit isReMaterializable = 0;
bit isPredicable = 0;
bit hasDelaySlot = 0;
bit usesCustomInserter = 0;
bit hasCtrlDep = 0;
bit isNotDuplicable = 0;
bit hasSideEffects = 0;
bit neverHasSideEffects = 0;
InstrItinClass Itinerary = NoItinerary;
string Constraints = "";
string DisableEncoding = "";
bits<8> Opcode = { 0, 0, 0, 0, 0, 0, 0, 1 };
Format Form = MRMDestReg;
bits<6> FormBits = { 0, 0, 0, 0, 1, 1 };
ImmType ImmT = NoImm;
bits<3> ImmTypeBits = { 0, 0, 0 };
bit hasOpSizePrefix = 0;
bit hasAdSizePrefix = 0;
bits<4> Prefix = { 0, 0, 0, 0 };
bit hasREX_WPrefix = 0;
FPFormat FPForm = ?;
bits<3> FPFormBits = { 0, 0, 0 };
}
...
This definition corresponds to the 32-bit register-register ``add`` instruction
of the x86 architecture. ``def ADD32rr`` defines a record named
``ADD32rr``, and the comment at the end of the line indicates the superclasses
of the definition. The body of the record contains all of the data that
TableGen assembled for the record, indicating that the instruction is part of
the "X86" namespace, the pattern indicating how the instruction should be
emitted into the assembly file, that it is a two-address instruction, has a
particular encoding, etc. The contents and semantics of the information in the
record are specific to the needs of the X86 backend, and are only shown as an
example.
As you can see, a lot of information is needed for every instruction supported
by the code generator, and specifying it all manually would be unmaintainable,
prone to bugs, and tiring to do in the first place. Because we are using
TableGen, all of the information was derived from the following definition:
.. code-block:: llvm
let Defs = [EFLAGS],
isCommutable = 1, // X = ADD Y,Z --> X = ADD Z,Y
isConvertibleToThreeAddress = 1 in // Can transform into LEA.
def ADD32rr : I<0x01, MRMDestReg, (outs GR32:$dst),
(ins GR32:$src1, GR32:$src2),
"add{l}\t{$src2, $dst|$dst, $src2}",
[(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>;
This definition makes use of the custom class ``I`` (extended from the custom
class ``X86Inst``), which is defined in the X86-specific TableGen file, to
factor out the common features that instructions of its class share. A key
feature of TableGen is that it allows the end-user to define the abstractions
they prefer to use when describing their information.
Each ``def`` record has a special entry called "NAME". This is the name of the
record ("``ADD32rr``" above). In the general case ``def`` names can be formed
from various kinds of string processing expressions and ``NAME`` resolves to the
final value obtained after resolving all of those expressions. The user may
refer to ``NAME`` anywhere she desires to use the ultimate name of the ``def``.
``NAME`` should not be defined anywhere else in user code to avoid conflicts.
Running TableGen
----------------
TableGen runs just like any other LLVM tool. The first (optional) argument
specifies the file to read. If a filename is not specified, ``llvm-tblgen``
reads from standard input.
To be useful, one of the `TableGen backends`_ must be used. These backends are
selectable on the command line (type '``llvm-tblgen -help``' for a list). For
example, to get a list of all of the definitions that subclass a particular type
(which can be useful for building up an enum list of these records), use the
``-print-enums`` option:
.. code-block:: bash
$ llvm-tblgen X86.td -print-enums -class=Register
AH, AL, AX, BH, BL, BP, BPL, BX, CH, CL, CX, DH, DI, DIL, DL, DX, EAX, EBP, EBX,
ECX, EDI, EDX, EFLAGS, EIP, ESI, ESP, FP0, FP1, FP2, FP3, FP4, FP5, FP6, IP,
MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7, R10, R10B, R10D, R10W, R11, R11B, R11D,
R11W, R12, R12B, R12D, R12W, R13, R13B, R13D, R13W, R14, R14B, R14D, R14W, R15,
R15B, R15D, R15W, R8, R8B, R8D, R8W, R9, R9B, R9D, R9W, RAX, RBP, RBX, RCX, RDI,
RDX, RIP, RSI, RSP, SI, SIL, SP, SPL, ST0, ST1, ST2, ST3, ST4, ST5, ST6, ST7,
XMM0, XMM1, XMM10, XMM11, XMM12, XMM13, XMM14, XMM15, XMM2, XMM3, XMM4, XMM5,
XMM6, XMM7, XMM8, XMM9,
$ llvm-tblgen X86.td -print-enums -class=Instruction
ABS_F, ABS_Fp32, ABS_Fp64, ABS_Fp80, ADC32mi, ADC32mi8, ADC32mr, ADC32ri,
ADC32ri8, ADC32rm, ADC32rr, ADC64mi32, ADC64mi8, ADC64mr, ADC64ri32, ADC64ri8,
ADC64rm, ADC64rr, ADD16mi, ADD16mi8, ADD16mr, ADD16ri, ADD16ri8, ADD16rm,
ADD16rr, ADD32mi, ADD32mi8, ADD32mr, ADD32ri, ADD32ri8, ADD32rm, ADD32rr,
ADD64mi32, ADD64mi8, ADD64mr, ADD64ri32, ...
The default backend prints out all of the records, as `described above`_.
If you plan to use TableGen, you will most likely have to `write a backend`_
that extracts the information specific to what you need and formats it in the
appropriate way.
.. _parses a file:
TableGen syntax
===============
TableGen doesn't care about the meaning of data (that is up to the backend to
define), but it does care about syntax, and it enforces a simple type system.
This section describes the syntax and the constructs allowed in a TableGen file.
TableGen primitives
-------------------
TableGen comments
^^^^^^^^^^^^^^^^^
TableGen supports BCPL style "``//``" comments, which run to the end of the
line, and it also supports **nestable** "``/* */``" comments.
.. _TableGen type:
The TableGen type system
^^^^^^^^^^^^^^^^^^^^^^^^
TableGen files are strongly typed, in a simple (but complete) type-system.
These types are used to perform automatic conversions, check for errors, and to
help interface designers constrain the input that they allow. Every `value
definition`_ is required to have an associated type.
TableGen supports a mixture of very low-level types (such as ``bit``) and very
high-level types (such as ``dag``). This flexibility is what allows it to
describe a wide range of information conveniently and compactly. The TableGen
types are:
``bit``
A 'bit' is a boolean value that can hold either 0 or 1.
``int``
The 'int' type represents a simple 32-bit integer value, such as 5.
``string``
The 'string' type represents an ordered sequence of characters of arbitrary
length.
``bits<n>``
A 'bits' type is an arbitrary, but fixed, size integer that is broken up
into individual bits. This type is useful because it can handle some bits
being defined while others are undefined.
``list<ty>``
This type represents a list whose elements are some other type. The
contained type is arbitrary: it can even be another list type.
Class type
Specifying a class name in a type context means that the defined value must
be a subclass of the specified class. This is useful in conjunction with
the ``list`` type, for example, to constrain the elements of the list to a
common base class (e.g., a ``list<Register>`` can only contain definitions
derived from the "``Register``" class).
``dag``
This type represents a nestable directed graph of elements.
To date, these types have been sufficient for describing things that TableGen
has been used for, but it is straight-forward to extend this list if needed.
.. _TableGen expressions:
TableGen values and expressions
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TableGen allows for a pretty reasonable number of different expression forms
when building up values. These forms allow the TableGen file to be written in a
natural syntax and flavor for the application. The current expression forms
supported include:
``?``
uninitialized field
``0b1001011``
binary integer value
``07654321``
octal integer value (indicated by a leading 0)
``7``
decimal integer value
``0x7F``
hexadecimal integer value
``"foo"``
string value
``[{ ... }]``
usually called a "code fragment", but is just a multiline string literal
``[ X, Y, Z ]<type>``
list value. <type> is the type of the list element and is usually optional.
In rare cases, TableGen is unable to deduce the element type in which case
the user must specify it explicitly.
``{ a, b, c }``
initializer for a "bits<3>" value
``value``
value reference
``value{17}``
access to one bit of a value
``value{15-17}``
access to multiple bits of a value
``DEF``
reference to a record definition
``CLASS<val list>``
reference to a new anonymous definition of CLASS with the specified template
arguments.
``X.Y``
reference to the subfield of a value
``list[4-7,17,2-3]``
A slice of the 'list' list, including elements 4,5,6,7,17,2, and 3 from it.
Elements may be included multiple times.
``foreach <var> = [ <list> ] in { <body> }``
``foreach <var> = [ <list> ] in <def>``
Replicate <body> or <def>, replacing instances of <var> with each value
in <list>. <var> is scoped at the level of the ``foreach`` loop and must
not conflict with any other object introduced in <body> or <def>. Currently
only ``def``\s are expanded within <body>.
``foreach <var> = 0-15 in ...``
``foreach <var> = {0-15,32-47} in ...``
Loop over ranges of integers. The braces are required for multiple ranges.
``(DEF a, b)``
a dag value. The first element is required to be a record definition, the
remaining elements in the list may be arbitrary other values, including
nested ```dag``' values.
``!strconcat(a, b)``
A string value that is the result of concatenating the 'a' and 'b' strings.
``str1#str2``
"#" (paste) is a shorthand for !strconcat. It may concatenate things that
are not quoted strings, in which case an implicit !cast<string> is done on
the operand of the paste.
``!cast<type>(a)``
A symbol of type *type* obtained by looking up the string 'a' in the symbol
table. If the type of 'a' does not match *type*, TableGen aborts with an
error. !cast<string> is a special case in that the argument must be an
object defined by a 'def' construct.
``!subst(a, b, c)``
If 'a' and 'b' are of string type or are symbol references, substitute 'b'
for 'a' in 'c.' This operation is analogous to $(subst) in GNU make.
``!foreach(a, b, c)``
For each member 'b' of dag or list 'a' apply operator 'c.' 'b' is a dummy
variable that should be declared as a member variable of an instantiated
class. This operation is analogous to $(foreach) in GNU make.
``!head(a)``
The first element of list 'a.'
``!tail(a)``
The 2nd-N elements of list 'a.'
``!empty(a)``
An integer {0,1} indicating whether list 'a' is empty.
``!if(a,b,c)``
'b' if the result of 'int' or 'bit' operator 'a' is nonzero, 'c' otherwise.
``!eq(a,b)``
'bit 1' if string a is equal to string b, 0 otherwise. This only operates
on string, int and bit objects. Use !cast<string> to compare other types of
objects.
Note that all of the values have rules specifying how they convert to values
for different types. These rules allow you to assign a value like "``7``"
to a "``bits<4>``" value, for example.
Classes and definitions
-----------------------
As mentioned in the `intro`_, classes and definitions (collectively known as
'records') in TableGen are the main high-level unit of information that TableGen
collects. Records are defined with a ``def`` or ``class`` keyword, the record
name, and an optional list of "`template arguments`_". If the record has
superclasses, they are specified as a comma separated list that starts with a
colon character ("``:``"). If `value definitions`_ or `let expressions`_ are
needed for the class, they are enclosed in curly braces ("``{}``"); otherwise,
the record ends with a semicolon.
Here is a simple TableGen file:
.. code-block:: llvm
class C { bit V = 1; }
def X : C;
def Y : C {
string Greeting = "hello";
}
This example defines two definitions, ``X`` and ``Y``, both of which derive from
the ``C`` class. Because of this, they both get the ``V`` bit value. The ``Y``
definition also gets the Greeting member as well.
In general, classes are useful for collecting together the commonality between a
group of records and isolating it in a single place. Also, classes permit the
specification of default values for their subclasses, allowing the subclasses to
override them as they wish.
.. _value definition:
.. _value definitions:
Value definitions
^^^^^^^^^^^^^^^^^
Value definitions define named entries in records. A value must be defined
before it can be referred to as the operand for another value definition or
before the value is reset with a `let expression`_. A value is defined by
specifying a `TableGen type`_ and a name. If an initial value is available, it
may be specified after the type with an equal sign. Value definitions require
terminating semicolons.
.. _let expression:
.. _let expressions:
.. _"let" expressions within a record:
'let' expressions
^^^^^^^^^^^^^^^^^
A record-level let expression is used to change the value of a value definition
in a record. This is primarily useful when a superclass defines a value that a
derived class or definition wants to override. Let expressions consist of the
'``let``' keyword followed by a value name, an equal sign ("``=``"), and a new
value. For example, a new class could be added to the example above, redefining
the ``V`` field for all of its subclasses:
.. code-block:: llvm
class D : C { let V = 0; }
def Z : D;
In this case, the ``Z`` definition will have a zero value for its ``V`` value,
despite the fact that it derives (indirectly) from the ``C`` class, because the
``D`` class overrode its value.
.. _template arguments:
Class template arguments
^^^^^^^^^^^^^^^^^^^^^^^^
TableGen permits the definition of parameterized classes as well as normal
concrete classes. Parameterized TableGen classes specify a list of variable
bindings (which may optionally have defaults) that are bound when used. Here is
a simple example:
.. code-block:: llvm
class FPFormat<bits<3> val> {
bits<3> Value = val;
}
def NotFP : FPFormat<0>;
def ZeroArgFP : FPFormat<1>;
def OneArgFP : FPFormat<2>;
def OneArgFPRW : FPFormat<3>;
def TwoArgFP : FPFormat<4>;
def CompareFP : FPFormat<5>;
def CondMovFP : FPFormat<6>;
def SpecialFP : FPFormat<7>;
In this case, template arguments are used as a space efficient way to specify a
list of "enumeration values", each with a "``Value``" field set to the specified
integer.
The more esoteric forms of `TableGen expressions`_ are useful in conjunction
with template arguments. As an example:
.. code-block:: llvm
class ModRefVal<bits<2> val> {
bits<2> Value = val;
}
def None : ModRefVal<0>;
def Mod : ModRefVal<1>;
def Ref : ModRefVal<2>;
def ModRef : ModRefVal<3>;
class Value<ModRefVal MR> {
// Decode some information into a more convenient format, while providing
// a nice interface to the user of the "Value" class.
bit isMod = MR.Value{0};
bit isRef = MR.Value{1};
// other stuff...
}
// Example uses
def bork : Value<Mod>;
def zork : Value<Ref>;
def hork : Value<ModRef>;
This is obviously a contrived example, but it shows how template arguments can
be used to decouple the interface provided to the user of the class from the
actual internal data representation expected by the class. In this case,
running ``llvm-tblgen`` on the example prints the following definitions:
.. code-block:: llvm
def bork { // Value
bit isMod = 1;
bit isRef = 0;
}
def hork { // Value
bit isMod = 1;
bit isRef = 1;
}
def zork { // Value
bit isMod = 0;
bit isRef = 1;
}
This shows that TableGen was able to dig into the argument and extract a piece
of information that was requested by the designer of the "Value" class. For
more realistic examples, please see existing users of TableGen, such as the X86
backend.
Multiclass definitions and instances
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
While classes with template arguments are a good way to factor commonality
between two instances of a definition, multiclasses allow a convenient notation
for defining multiple definitions at once (instances of implicitly constructed
classes). For example, consider an 3-address instruction set whose instructions
come in two forms: "``reg = reg op reg``" and "``reg = reg op imm``"
(e.g. SPARC). In this case, you'd like to specify in one place that this
commonality exists, then in a separate place indicate what all the ops are.
Here is an example TableGen fragment that shows this idea:
.. code-block:: llvm
def ops;
def GPR;
def Imm;
class inst<int opc, string asmstr, dag operandlist>;
multiclass ri_inst<int opc, string asmstr> {
def _rr : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
(ops GPR:$dst, GPR:$src1, GPR:$src2)>;
def _ri : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
(ops GPR:$dst, GPR:$src1, Imm:$src2)>;
}
// Instantiations of the ri_inst multiclass.
defm ADD : ri_inst<0b111, "add">;
defm SUB : ri_inst<0b101, "sub">;
defm MUL : ri_inst<0b100, "mul">;
...
The name of the resultant definitions has the multidef fragment names appended
to them, so this defines ``ADD_rr``, ``ADD_ri``, ``SUB_rr``, etc. A defm may
inherit from multiple multiclasses, instantiating definitions from each
multiclass. Using a multiclass this way is exactly equivalent to instantiating
the classes multiple times yourself, e.g. by writing:
.. code-block:: llvm
def ops;
def GPR;
def Imm;
class inst<int opc, string asmstr, dag operandlist>;
class rrinst<int opc, string asmstr>
: inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
(ops GPR:$dst, GPR:$src1, GPR:$src2)>;
class riinst<int opc, string asmstr>
: inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
(ops GPR:$dst, GPR:$src1, Imm:$src2)>;
// Instantiations of the ri_inst multiclass.
def ADD_rr : rrinst<0b111, "add">;
def ADD_ri : riinst<0b111, "add">;
def SUB_rr : rrinst<0b101, "sub">;
def SUB_ri : riinst<0b101, "sub">;
def MUL_rr : rrinst<0b100, "mul">;
def MUL_ri : riinst<0b100, "mul">;
...
A ``defm`` can also be used inside a multiclass providing several levels of
multiclass instantiations.
.. code-block:: llvm
class Instruction<bits<4> opc, string Name> {
bits<4> opcode = opc;
string name = Name;
}
multiclass basic_r<bits<4> opc> {
def rr : Instruction<opc, "rr">;
def rm : Instruction<opc, "rm">;
}
multiclass basic_s<bits<4> opc> {
defm SS : basic_r<opc>;
defm SD : basic_r<opc>;
def X : Instruction<opc, "x">;
}
multiclass basic_p<bits<4> opc> {
defm PS : basic_r<opc>;
defm PD : basic_r<opc>;
def Y : Instruction<opc, "y">;
}
defm ADD : basic_s<0xf>, basic_p<0xf>;
...
// Results
def ADDPDrm { ...
def ADDPDrr { ...
def ADDPSrm { ...
def ADDPSrr { ...
def ADDSDrm { ...
def ADDSDrr { ...
def ADDY { ...
def ADDX { ...
``defm`` declarations can inherit from classes too, the rule to follow is that
the class list must start after the last multiclass, and there must be at least
one multiclass before them.
.. code-block:: llvm
class XD { bits<4> Prefix = 11; }
class XS { bits<4> Prefix = 12; }
class I<bits<4> op> {
bits<4> opcode = op;
}
multiclass R {
def rr : I<4>;
def rm : I<2>;
}
multiclass Y {
defm SS : R, XD;
defm SD : R, XS;
}
defm Instr : Y;
// Results
def InstrSDrm {
bits<4> opcode = { 0, 0, 1, 0 };
bits<4> Prefix = { 1, 1, 0, 0 };
}
...
def InstrSSrr {
bits<4> opcode = { 0, 1, 0, 0 };
bits<4> Prefix = { 1, 0, 1, 1 };
}
File scope entities
-------------------
File inclusion
^^^^^^^^^^^^^^
TableGen supports the '``include``' token, which textually substitutes the
specified file in place of the include directive. The filename should be
specified as a double quoted string immediately after the '``include``' keyword.
Example:
.. code-block:: llvm
include "foo.td"
'let' expressions
^^^^^^^^^^^^^^^^^
"Let" expressions at file scope are similar to `"let" expressions within a
record`_, except they can specify a value binding for multiple records at a
time, and may be useful in certain other cases. File-scope let expressions are
really just another way that TableGen allows the end-user to factor out
commonality from the records.
File-scope "let" expressions take a comma-separated list of bindings to apply,
and one or more records to bind the values in. Here are some examples:
.. code-block:: llvm
let isTerminator = 1, isReturn = 1, isBarrier = 1, hasCtrlDep = 1 in
def RET : I<0xC3, RawFrm, (outs), (ins), "ret", [(X86retflag 0)]>;
let isCall = 1 in
// All calls clobber the non-callee saved registers...
let Defs = [EAX, ECX, EDX, FP0, FP1, FP2, FP3, FP4, FP5, FP6, ST0,
MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7,
XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, XMM7, EFLAGS] in {
def CALLpcrel32 : Ii32<0xE8, RawFrm, (outs), (ins i32imm:$dst,variable_ops),
"call\t${dst:call}", []>;
def CALL32r : I<0xFF, MRM2r, (outs), (ins GR32:$dst, variable_ops),
"call\t{*}$dst", [(X86call GR32:$dst)]>;
def CALL32m : I<0xFF, MRM2m, (outs), (ins i32mem:$dst, variable_ops),
"call\t{*}$dst", []>;
}
File-scope "let" expressions are often useful when a couple of definitions need
to be added to several records, and the records do not otherwise need to be
opened, as in the case with the ``CALL*`` instructions above.
It's also possible to use "let" expressions inside multiclasses, providing more
ways to factor out commonality from the records, specially if using several
levels of multiclass instantiations. This also avoids the need of using "let"
expressions within subsequent records inside a multiclass.
.. code-block:: llvm
multiclass basic_r<bits<4> opc> {
let Predicates = [HasSSE2] in {
def rr : Instruction<opc, "rr">;
def rm : Instruction<opc, "rm">;
}
let Predicates = [HasSSE3] in
def rx : Instruction<opc, "rx">;
}
multiclass basic_ss<bits<4> opc> {
let IsDouble = 0 in
defm SS : basic_r<opc>;
let IsDouble = 1 in
defm SD : basic_r<opc>;
}
defm ADD : basic_ss<0xf>;
Looping
^^^^^^^
TableGen supports the '``foreach``' block, which textually replicates the loop
body, substituting iterator values for iterator references in the body.
Example:
.. code-block:: llvm
foreach i = [0, 1, 2, 3] in {
def R#i : Register<...>;
def F#i : Register<...>;
}
This will create objects ``R0``, ``R1``, ``R2`` and ``R3``. ``foreach`` blocks
may be nested. If there is only one item in the body the braces may be
elided:
.. code-block:: llvm
foreach i = [0, 1, 2, 3] in
def R#i : Register<...>;
Code Generator backend info
===========================
Expressions used by code generator to describe instructions and isel patterns:
``(implicit a)``
an implicitly defined physical register. This tells the dag instruction
selection emitter the input pattern's extra definitions matches implicit
physical register definitions.
.. _TableGen backend:
.. _TableGen backends:
.. _write a backend:
TableGen backends
=================
Until we get a step-by-step HowTo for writing TableGen backends, you can at
least grab the boilerplate (build system, new files, etc.) from Clang's
r173931.
TODO: How they work, how to write one. This section should not contain details
about any particular backend, except maybe ``-print-enums`` as an example. This
should highlight the APIs in ``TableGen/Record.h``.
The TableGen fundamentals documentation has moved to a directory on its own
and is now available at :doc:`TableGen/index`. Please, change your links to
that page.

9
external/bsd/llvm/dist/llvm/docs/Vectorizers.rst vendored
View File

@ -182,11 +182,14 @@ that scatter/gathers memory.
.. code-block:: c++
int foo(int *A, int *B, int n, int k) {
for (int i = 0; i < n; ++i)
A[i*7] += B[i*k];
int foo(int * A, int * B, int n) {
for (intptr_t i = 0; i < n; ++i)
A[i] += B[i * 4];
}
In many situations the cost model will inform LLVM that this is not beneficial
and LLVM will only vectorize such code if forced with "-mllvm -force-vector-width=#".
Vectorization of Mixed Types
^^^^^^^^^^^^^^^^^^^^^^^^^^^^

2
external/bsd/llvm/dist/llvm/docs/WritingAnLLVMBackend.rst vendored
View File

@ -51,7 +51,7 @@ These essential documents must be read before reading this document:
Formation, SSA-based Optimization, Register Allocation, Prolog/Epilog Code
Insertion, Late Machine Code Optimizations, and Code Emission.
* :doc:`TableGenFundamentals` --- a document that describes the TableGen
* :doc:`TableGen/index` --- a document that describes the TableGen
(``tblgen``) application that manages domain-specific information to support
LLVM code generation. TableGen processes input from a target description
file (``.td`` suffix) and generates C++ code that can be used for code

40
external/bsd/llvm/dist/llvm/docs/YamlIO.rst vendored
View File

@ -399,6 +399,42 @@ the above schema, a same valid YAML document is:
name: Tom
flags: [ pointy, flat ]
Sometimes a "flags" field might contains an enumeration part
defined by a bit-mask.
.. code-block:: c++
enum {
flagsFeatureA = 1,
flagsFeatureB = 2,
flagsFeatureC = 4,
flagsCPUMask = 24,
flagsCPU1 = 8,
flagsCPU2 = 16
};
To support reading and writing such fields, you need to use the maskedBitSet()
method and provide the bit values, their names and the enumeration mask.
.. code-block:: c++
template <>
struct ScalarBitSetTraits<MyFlags> {
static void bitset(IO &io, MyFlags &value) {
io.bitSetCase(value, "featureA", flagsFeatureA);
io.bitSetCase(value, "featureB", flagsFeatureB);
io.bitSetCase(value, "featureC", flagsFeatureC);
io.maskedBitSetCase(value, "CPU1", flagsCPU1, flagsCPUMask);
io.maskedBitSetCase(value, "CPU2", flagsCPU2, flagsCPUMask);
}
};
YAML I/O (when writing) will apply the enumeration mask to the flags field,
and compare the result and values from the bitset. As in case of a regular
bitset, each that matches will cause the corresponding string to be added
to the flow sequence.
Custom Scalar
-------------
@ -426,8 +462,10 @@ looks like:
static StringRef input(StringRef scalar, T &value) {
// do custom parsing here. Return the empty string on success,
// or an error message on failure.
return StringRef();
return StringRef();
}
// Determine if this scalar needs quotes.
static bool mustQuote(StringRef) { return true; }
};

62
external/bsd/llvm/dist/llvm/docs/doxygen.cfg.in vendored
View File

@ -938,58 +938,58 @@ BINARY_TOC = NO
TOC_EXPAND = NO
# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and
# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated
# that can be used as input for Qt's qhelpgenerator to generate a
# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and
# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated
# that can be used as input for Qt's qhelpgenerator to generate a
# Qt Compressed Help (.qch) of the generated HTML documentation.
GENERATE_QHP = NO
GENERATE_QHP = @llvm_doxygen_generate_qhp@
# If the QHG_LOCATION tag is specified, the QCH_FILE tag can
# be used to specify the file name of the resulting .qch file.
# If the QHG_LOCATION tag is specified, the QCH_FILE tag can
# be used to specify the file name of the resulting .qch file.
# The path specified is relative to the HTML output folder.
QCH_FILE =
QCH_FILE = @llvm_doxygen_qch_filename@
# The QHP_NAMESPACE tag specifies the namespace to use when generating
# Qt Help Project output. For more information please see
# http://doc.trolltech.com/qthelpproject.html#namespace
# The QHP_NAMESPACE tag specifies the namespace to use when generating
# Qt Help Project output. For more information please see
# http://qt-project.org/doc/qt-4.8/qthelpproject.html#namespace
QHP_NAMESPACE = org.doxygen.Project
QHP_NAMESPACE = @llvm_doxygen_qhp_namespace@
# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating
# Qt Help Project output. For more information please see
# http://doc.trolltech.com/qthelpproject.html#virtual-folders
# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating
# Qt Help Project output. For more information please see
# http://qt-project.org/doc/qt-4.8/qthelpproject.html#virtual-folders
QHP_VIRTUAL_FOLDER = doc
# If QHP_CUST_FILTER_NAME is set, it specifies the name of a custom filter to
# add. For more information please see
# http://doc.trolltech.com/qthelpproject.html#custom-filters
# If QHP_CUST_FILTER_NAME is set, it specifies the name of a custom filter to
# add. For more information please see
# http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-filters
QHP_CUST_FILTER_NAME =
QHP_CUST_FILTER_NAME = @llvm_doxygen_qhp_cust_filter_name@
# The QHP_CUST_FILT_ATTRS tag specifies the list of the attributes of the
# custom filter to add. For more information please see
# <a href="http://doc.trolltech.com/qthelpproject.html#custom-filters">
# The QHP_CUST_FILT_ATTRS tag specifies the list of the attributes of the
# custom filter to add. For more information please see
# <a href="http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom-filters">
# Qt Help Project / Custom Filters</a>.
QHP_CUST_FILTER_ATTRS =
QHP_CUST_FILTER_ATTRS = @llvm_doxygen_qhp_cust_filter_attrs@
# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this
# project's
# filter section matches.
# <a href="http://doc.trolltech.com/qthelpproject.html#filter-attributes">
# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this
# project's
# filter section matches.
# <a href="http://qt-project.org/doc/qt-4.8/qthelpproject.html#filter-attributes">
# Qt Help Project / Filter Attributes</a>.
QHP_SECT_FILTER_ATTRS =
QHP_SECT_FILTER_ATTRS =
# If the GENERATE_QHP tag is set to YES, the QHG_LOCATION tag can
# be used to specify the location of Qt's qhelpgenerator.
# If non-empty doxygen will try to run qhelpgenerator on the generated
# If the GENERATE_QHP tag is set to YES, the QHG_LOCATION tag can
# be used to specify the location of Qt's qhelpgenerator.
# If non-empty doxygen will try to run qhelpgenerator on the generated
# .qhp file.
QHG_LOCATION =
QHG_LOCATION = @llvm_doxygen_qhelpgenerator_path@
# If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files
# will be generated, which together with the HTML files, form an Eclipse help

16
external/bsd/llvm/dist/llvm/docs/index.rst vendored
View File

@ -215,6 +215,7 @@ For API clients and LLVM developers.
AliasAnalysis
BitCodeFormat
BlockFrequencyTerminology
BranchWeightMetadata
Bugpoint
CodeGenerator
@ -222,6 +223,7 @@ For API clients and LLVM developers.
LinkTimeOptimization
SegmentedStacks
TableGenFundamentals
TableGen/index
DebuggingJITedCode
GoldPlugin
MarkedUpDisassembly
@ -231,10 +233,11 @@ For API clients and LLVM developers.
WritingAnLLVMBackend
GarbageCollection
WritingAnLLVMPass
TableGen/LangRef
HowToUseAttributes
NVPTXUsage
StackMaps
InAlloca
BigEndianNEON
:doc:`WritingAnLLVMPass`
Information on how to write LLVM transformations and analyses.
@ -247,7 +250,7 @@ For API clients and LLVM developers.
working on retargetting LLVM to a new architecture, designing a new codegen
pass, or enhancing existing components.
:doc:`TableGenFundamentals`
:doc:`TableGen <TableGen/index>`
Describes the TableGen tool, which is used heavily by the LLVM code
generator.
@ -297,6 +300,10 @@ For API clients and LLVM developers.
:doc:`BranchWeightMetadata`
Provides information about Branch Prediction Information.
:doc:`BlockFrequencyTerminology`
Provides information about terminology used in the ``BlockFrequencyInfo``
analysis pass.
:doc:`SegmentedStacks`
This document describes segmented stacks and how they are used in LLVM.
@ -313,6 +320,11 @@ For API clients and LLVM developers.
LLVM support for mapping instruction addresses to the location of
values and allowing code to be patched.
:doc:`BigEndianNEON`
LLVM's support for generating NEON instructions on big endian ARM targets is
somewhat nonintuitive. This document explains the implementation and rationale.
Development Process Documentation
=================================

2
external/bsd/llvm/dist/llvm/docs/yaml2obj.rst vendored
View File

@ -64,7 +64,7 @@ Here's a simplified Kwalify_ schema with an extension to allow alternate types.
, IMAGE_FILE_MACHINE_AM33
, IMAGE_FILE_MACHINE_AMD64
, IMAGE_FILE_MACHINE_ARM
, IMAGE_FILE_MACHINE_ARMV7
, IMAGE_FILE_MACHINE_ARMNT
, IMAGE_FILE_MACHINE_EBC
, IMAGE_FILE_MACHINE_I386
, IMAGE_FILE_MACHINE_IA64

1
external/bsd/llvm/dist/llvm/examples/BrainF/BrainFDriver.cpp vendored
View File

@ -31,6 +31,7 @@
#include "llvm/IR/Constants.h"
#include "llvm/IR/Verifier.h"
#include "llvm/Support/CommandLine.h"
#include "llvm/Support/FileSystem.h"
#include "llvm/Support/ManagedStatic.h"
#include "llvm/Support/TargetSelect.h"
#include "llvm/Support/raw_ostream.h"

2
external/bsd/llvm/dist/llvm/examples/Fibonacci/fibonacci.cpp vendored
View File

@ -96,7 +96,7 @@ int main(int argc, char **argv) {
LLVMContext Context;
// Create some module to put our function into it.
OwningPtr<Module> M(new Module("test", Context));
std::unique_ptr<Module> M(new Module("test", Context));
// We are about to create the "fib" function:
Function *FibF = CreateFibFunction(M.get(), Context);

2
external/bsd/llvm/dist/llvm/examples/Kaleidoscope/MCJIT/cached/toy.cpp vendored
View File

@ -715,7 +715,7 @@ public:
// This file isn't in our cache
return NULL;
}
OwningPtr<MemoryBuffer> IRObjectBuffer;
std::unique_ptr<MemoryBuffer> IRObjectBuffer;
MemoryBuffer::getFile(IRCacheFile.c_str(), IRObjectBuffer, -1, false);
// MCJIT will want to write into this buffer, and we don't want that
// because the file has probably just been mmapped. Instead we make

2
external/bsd/llvm/dist/llvm/examples/Kaleidoscope/MCJIT/complete/toy.cpp vendored
View File

@ -739,7 +739,7 @@ public:
// This file isn't in our cache
return NULL;
}
OwningPtr<MemoryBuffer> IRObjectBuffer;
std::unique_ptr<MemoryBuffer> IRObjectBuffer;
MemoryBuffer::getFile(IRCacheFile.c_str(), IRObjectBuffer, -1, false);
// MCJIT will want to write into this buffer, and we don't want that
// because the file has probably just been mmapped. Instead we make

3
external/bsd/llvm/dist/llvm/examples/ParallelJIT/ParallelJIT.cpp vendored
View File

@ -139,6 +139,7 @@ public:
~WaitForThreads()
{
int result = pthread_cond_destroy( &condition );
(void)result;
assert( result == 0 );
result = pthread_mutex_destroy( &mutex );
@ -149,6 +150,7 @@ public:
void block()
{
int result = pthread_mutex_lock( &mutex );
(void)result;
assert( result == 0 );
n ++;
//~ std::cout << "block() n " << n << " waitFor " << waitFor << std::endl;
@ -178,6 +180,7 @@ public:
void releaseThreads( size_t num )
{
int result = pthread_mutex_lock( &mutex );
(void)result;
assert( result == 0 );
if ( n >= num ) {

77
external/bsd/llvm/dist/llvm/include/llvm-c/Core.h vendored
View File

@ -15,7 +15,7 @@
#ifndef LLVM_C_CORE_H
#define LLVM_C_CORE_H
#include "llvm/Support/DataTypes.h"
#include "llvm-c/Support.h"
#ifdef __cplusplus
extern "C" {
@ -62,8 +62,6 @@ extern "C" {
* @{
*/
typedef int LLVMBool;
/* Opaque types. */
/**
@ -114,13 +112,6 @@ typedef struct LLVMOpaqueBuilder *LLVMBuilderRef;
*/
typedef struct LLVMOpaqueModuleProvider *LLVMModuleProviderRef;
/**
* Used to provide a module to JIT or interpreter.
*
* @see llvm::MemoryBuffer
*/
typedef struct LLVMOpaqueMemoryBuffer *LLVMMemoryBufferRef;
/** @see llvm::PassManagerBase */
typedef struct LLVMOpaquePassManager *LLVMPassManagerRef;
@ -133,6 +124,12 @@ typedef struct LLVMOpaquePassRegistry *LLVMPassRegistryRef;
* @see llvm::Use */
typedef struct LLVMOpaqueUse *LLVMUseRef;
/**
* @see llvm::DiagnosticInfo
*/
typedef struct LLVMOpaqueDiagnosticInfo *LLVMDiagnosticInfoRef;
typedef enum {
LLVMZExtAttribute = 1<<0,
LLVMSExtAttribute = 1<<1,
@ -168,7 +165,8 @@ typedef enum {
LLVMStackProtectStrongAttribute = 1ULL<<33,
LLVMCold = 1ULL << 34,
LLVMOptimizeNone = 1ULL << 35,
LLVMInAllocaAttribute = 1ULL << 36
LLVMInAllocaAttribute = 1ULL << 36,
LLVMNonNullAttribute = 1ULL << 37
*/
} LLVMAttribute;
@ -299,6 +297,12 @@ typedef enum {
LLVMProtectedVisibility /**< The GV is protected */
} LLVMVisibility;
typedef enum {
LLVMDefaultStorageClass = 0,
LLVMDLLImportStorageClass = 1, /**< Function to be imported from DLL. */
LLVMDLLExportStorageClass = 2 /**< Function to be accessible from DLL. */
} LLVMDLLStorageClass;
typedef enum {
LLVMCCallConv = 0,
LLVMFastCallConv = 8,
@ -403,6 +407,13 @@ typedef enum {
the old one */
} LLVMAtomicRMWBinOp;
typedef enum {
LLVMDSError,
LLVMDSWarning,
LLVMDSRemark,
LLVMDSNote
} LLVMDiagnosticSeverity;
/**
* @}
*/
@ -456,6 +467,9 @@ void LLVMEnablePrettyStackTrace(void);
* @{
*/
typedef void (*LLVMDiagnosticHandler)(LLVMDiagnosticInfoRef, void *);
typedef void (*LLVMYieldCallback)(LLVMContextRef, void *);
/**
* Create a new context.
*
@ -469,6 +483,21 @@ LLVMContextRef LLVMContextCreate(void);
*/
LLVMContextRef LLVMGetGlobalContext(void);
/**
* Set the diagnostic handler for this context.
*/
void LLVMContextSetDiagnosticHandler(LLVMContextRef C,
LLVMDiagnosticHandler Handler,
void *DiagnosticContext);
/**
* Set the yield callback function for this context.
*
* @see LLVMContext::setYieldCallback()
*/
void LLVMContextSetYieldCallback(LLVMContextRef C, LLVMYieldCallback Callback,
void *OpaqueHandle);
/**
* Destroy a context instance.
*
@ -477,6 +506,21 @@ LLVMContextRef LLVMGetGlobalContext(void);
*/
void LLVMContextDispose(LLVMContextRef C);
/**
* Return a string representation of the DiagnosticInfo. Use
* LLVMDisposeMessage to free the string.
*
* @see DiagnosticInfo::print()
*/
char *LLVMGetDiagInfoDescription(LLVMDiagnosticInfoRef DI);
/**
* Return an enum LLVMDiagnosticSeverity.
*
* @see DiagnosticInfo::getSeverity()
*/
LLVMDiagnosticSeverity LLVMGetDiagInfoSeverity(LLVMDiagnosticInfoRef DI);
unsigned LLVMGetMDKindIDInContext(LLVMContextRef C, const char* Name,
unsigned SLen);
unsigned LLVMGetMDKindID(const char* Name, unsigned SLen);
@ -1124,9 +1168,10 @@ LLVMTypeRef LLVMX86MMXType(void);
macro(ConstantStruct) \
macro(ConstantVector) \
macro(GlobalValue) \
macro(Function) \
macro(GlobalAlias) \
macro(GlobalVariable) \
macro(GlobalObject) \
macro(Function) \
macro(GlobalVariable) \
macro(UndefValue) \
macro(Instruction) \
macro(BinaryOperator) \
@ -1689,6 +1734,10 @@ const char *LLVMGetSection(LLVMValueRef Global);
void LLVMSetSection(LLVMValueRef Global, const char *Section);
LLVMVisibility LLVMGetVisibility(LLVMValueRef Global);
void LLVMSetVisibility(LLVMValueRef Global, LLVMVisibility Viz);
LLVMDLLStorageClass LLVMGetDLLStorageClass(LLVMValueRef Global);
void LLVMSetDLLStorageClass(LLVMValueRef Global, LLVMDLLStorageClass Class);
LLVMBool LLVMHasUnnamedAddr(LLVMValueRef Global);
void LLVMSetUnnamedAddr(LLVMValueRef Global, LLVMBool HasUnnamedAddr);
/**
* @defgroup LLVMCCoreValueWithAlignment Values with alignment
@ -1699,6 +1748,7 @@ void LLVMSetVisibility(LLVMValueRef Global, LLVMVisibility Viz);
/**
* Obtain the preferred alignment of the value.
* @see llvm::AllocaInst::getAlignment()
* @see llvm::LoadInst::getAlignment()
* @see llvm::StoreInst::getAlignment()
* @see llvm::GlobalValue::getAlignment()
@ -1707,6 +1757,7 @@ unsigned LLVMGetAlignment(LLVMValueRef V);
/**
* Set the preferred alignment of the value.
* @see llvm::AllocaInst::setAlignment()
* @see llvm::LoadInst::setAlignment()
* @see llvm::StoreInst::setAlignment()
* @see llvm::GlobalValue::setAlignment()

21
external/bsd/llvm/dist/llvm/include/llvm-c/Disassembler.h vendored
View File

@ -95,6 +95,16 @@ struct LLVMOpInfo1 {
#define LLVMDisassembler_VariantKind_ARM_HI16 1 /* :upper16: */
#define LLVMDisassembler_VariantKind_ARM_LO16 2 /* :lower16: */
/**
* The ARM64 target VariantKinds.
*/
#define LLVMDisassembler_VariantKind_ARM64_PAGE 1 /* @page */
#define LLVMDisassembler_VariantKind_ARM64_PAGEOFF 2 /* @pageoff */
#define LLVMDisassembler_VariantKind_ARM64_GOTPAGE 3 /* @gotpage */
#define LLVMDisassembler_VariantKind_ARM64_GOTPAGEOFF 4 /* @gotpageoff */
#define LLVMDisassembler_VariantKind_ARM64_TLVP 5 /* @tvlppage */
#define LLVMDisassembler_VariantKind_ARM64_TLVOFF 6 /* @tvlppageoff */
/**
* The type for the symbol lookup function. This may be called by the
* disassembler for things like adding a comment for a PC plus a constant
@ -123,6 +133,17 @@ typedef const char *(*LLVMSymbolLookupCallback)(void *DisInfo,
/* The input reference is from a PC relative load instruction. */
#define LLVMDisassembler_ReferenceType_In_PCrel_Load 2
/* The input reference is from an ARM64::ADRP instruction. */
#define LLVMDisassembler_ReferenceType_In_ARM64_ADRP 0x100000001
/* The input reference is from an ARM64::ADDXri instruction. */
#define LLVMDisassembler_ReferenceType_In_ARM64_ADDXri 0x100000002
/* The input reference is from an ARM64::LDRXui instruction. */
#define LLVMDisassembler_ReferenceType_In_ARM64_LDRXui 0x100000003
/* The input reference is from an ARM64::LDRXl instruction. */
#define LLVMDisassembler_ReferenceType_In_ARM64_LDRXl 0x100000004
/* The input reference is from an ARM64::ADR instruction. */
#define LLVMDisassembler_ReferenceType_In_ARM64_ADR 0x100000005
/* The output reference is to as symbol stub. */
#define LLVMDisassembler_ReferenceType_Out_SymbolStub 1
/* The output reference is to a symbol address in a literal pool. */

1
external/bsd/llvm/dist/llvm/include/llvm-c/Object.h vendored
View File

@ -78,7 +78,6 @@ void LLVMMoveToNextRelocation(LLVMRelocationIteratorRef RI);
// SymbolRef accessors
const char *LLVMGetSymbolName(LLVMSymbolIteratorRef SI);
uint64_t LLVMGetSymbolAddress(LLVMSymbolIteratorRef SI);
uint64_t LLVMGetSymbolFileOffset(LLVMSymbolIteratorRef SI);
uint64_t LLVMGetSymbolSize(LLVMSymbolIteratorRef SI);
// RelocationRef accessors

21
external/bsd/llvm/dist/llvm/include/llvm-c/Support.h vendored
View File

@ -14,12 +14,31 @@
#ifndef LLVM_C_SUPPORT_H
#define LLVM_C_SUPPORT_H
#include "llvm-c/Core.h"
#include "llvm/Support/DataTypes.h"
#ifdef __cplusplus
extern "C" {
#endif
/**
* @defgroup LLVMCSupportTypes Types and Enumerations
*
* @{
*/
typedef int LLVMBool;
/**
* Used to pass regions of memory through LLVM interfaces.
*
* @see llvm::MemoryBuffer
*/
typedef struct LLVMOpaqueMemoryBuffer *LLVMMemoryBufferRef;
/**
* @}
*/
/**
* This function permanently loads the dynamic library at the given path.
* It is safe to call this function multiple times for the same library.

1
external/bsd/llvm/dist/llvm/include/llvm-c/Transforms/PassManagerBuilder.h vendored
View File

@ -19,7 +19,6 @@
typedef struct LLVMOpaquePassManagerBuilder *LLVMPassManagerBuilderRef;
#ifdef __cplusplus
#include "llvm/Transforms/IPO/PassManagerBuilder.h"
extern "C" {
#endif

41
external/bsd/llvm/dist/llvm/include/llvm-c/lto.h vendored
View File

@ -40,7 +40,7 @@ typedef bool lto_bool_t;
* @{
*/
#define LTO_API_VERSION 10
#define LTO_API_VERSION 11
/**
* \since prior to LTO_API_VERSION=3
@ -79,23 +79,15 @@ typedef enum {
typedef enum {
LTO_CODEGEN_PIC_MODEL_STATIC = 0,
LTO_CODEGEN_PIC_MODEL_DYNAMIC = 1,
LTO_CODEGEN_PIC_MODEL_DYNAMIC_NO_PIC = 2
LTO_CODEGEN_PIC_MODEL_DYNAMIC_NO_PIC = 2,
LTO_CODEGEN_PIC_MODEL_DEFAULT = 3
} lto_codegen_model;
/**
* \since LTO_API_VERSION=6
*/
typedef enum {
LTO_INTERNALIZE_FULL = 0,
LTO_INTERNALIZE_NONE = 1,
LTO_INTERNALIZE_HIDDEN = 2
} lto_internalize_strategy;
/** opaque reference to a loaded object module */
typedef struct LTOModule* lto_module_t;
typedef struct LLVMOpaqueLTOModule *lto_module_t;
/** opaque reference to a code generator */
typedef struct LTOCodeGenerator* lto_code_gen_t;
typedef struct LLVMOpaqueLTOCodeGenerator *lto_code_gen_t;
#ifdef __cplusplus
extern "C" {
@ -383,6 +375,14 @@ lto_codegen_set_pic_model(lto_code_gen_t cg, lto_codegen_model);
extern void
lto_codegen_set_cpu(lto_code_gen_t cg, const char *cpu);
/**
* Sets attributes for the cpu to generate code for.
*
* \since LTO_API_VERSION=11
*/
extern void
lto_codegen_set_attr(lto_code_gen_t cg, const char *attr);
/**
* Sets the location of the assembler tool to run. If not set, libLTO
@ -403,18 +403,9 @@ lto_codegen_set_assembler_args(lto_code_gen_t cg, const char **args,
int nargs);
/**
* Sets the strategy to use during internalize. Default strategy is
* LTO_INTERNALIZE_FULL.
*
* \since LTO_API_VERSION=6
*/
extern void
lto_codegen_set_internalize_strategy(lto_code_gen_t cg,
lto_internalize_strategy);
/**
* Tells LTO optimization passes that this symbol must be preserved
* because it is referenced by native code or a command line option.
* Adds to a list of all global symbols that must exist in the final generated
* code. If a function is not listed there, it might be inlined into every usage
* and optimized away.
*
* \since prior to LTO_API_VERSION=3
*/

5
external/bsd/llvm/dist/llvm/include/llvm-c/module.modulemap vendored Normal file
View File

@ -0,0 +1,5 @@
module LLVM_C {
requires cplusplus
umbrella "."
module * { export * }
}

Some files were not shown because too many files have changed in this diff Show More