Compare commits

..

20 Commits

Author SHA1 Message Date
John Criswell
3c357fb4b0 Added Stacker Reid Spencer's contributions.
llvm-svn: 10498
2003-12-17 20:37:38 +00:00
John Criswell
a0877e6620 Fixed some punctuation and grammar.
llvm-svn: 10486
2003-12-16 17:31:42 +00:00
John Criswell
da45ebd298 Not ready for prime-time.
llvm-svn: 10485
2003-12-16 16:56:10 +00:00
John Criswell
0dd5964f48 Updated for release 1.1.
Added information on FreeBSD and MacOS X.

llvm-svn: 10484
2003-12-16 16:26:26 +00:00
John Criswell
e70acef70b Fixed a minor spelling error.
llvm-svn: 10482
2003-12-15 23:08:32 +00:00
John Criswell
4bee8e0a3a Added all known bugs that are relevant and relatively concrete.
llvm-svn: 10481
2003-12-15 23:04:43 +00:00
Misha Brukman
8f7bf8914a * Unbroke our HTML-4.01 compliance!
* Added note about PR186: present in 1.1, fixed in 1.2

llvm-svn: 10480
2003-12-15 22:57:49 +00:00
John Criswell
b549680585 Updated version number to 1.1.
Thanks, Chris!

llvm-svn: 10477
2003-12-15 22:12:50 +00:00
John Criswell
53ee4b83bb Grammatical and punctuation corrections.
llvm-svn: 10476
2003-12-15 21:05:22 +00:00
Chris Lattner
d5d184faac merge testcase from mainline
llvm-svn: 10475
2003-12-15 17:35:57 +00:00
Chris Lattner
eea45bf361 Merge from mainline, bugfix for PR185
llvm-svn: 10474
2003-12-15 17:35:09 +00:00
CVS to SVN Conversion
be0de4d917 This commit was manufactured by cvs2svn to create branch 'release_11'.
llvm-svn: 10472
2003-12-15 17:33:41 +00:00
John Criswell
d102fe3a95 Added obligatory copyright notices from HP and SGI.
llvm-svn: 10454
2003-12-13 21:25:39 +00:00
John Criswell
e7faf76bef Indicate that the pathname to the LLVM GCC front end must be an
absolute pathname.  This burnt me on a Sparc build.

llvm-svn: 10453
2003-12-13 19:45:28 +00:00
John Criswell
6496cf1d2a Don't specify the pointer size or endian-ness; it won't match for certain
platforms (SparcV9).

llvm-svn: 10452
2003-12-13 17:19:23 +00:00
John Criswell
84da4a6965 Added information on fixing libstdc++ on Solaris 8.
llvm-svn: 10451
2003-12-13 16:09:30 +00:00
Chris Lattner
5da0c61395 Minor cleanups, expand on what's new, give credit for the release notes to the whole team, not just me
llvm-svn: 10443
2003-12-12 23:21:29 +00:00
Chris Lattner
8d76ed912c Mac OS/X -> Mac OS X
llvm-svn: 10442
2003-12-12 23:15:37 +00:00
Chris Lattner
807a8cfe7a merge from mainline
llvm-svn: 10441
2003-12-12 21:34:10 +00:00
CVS to SVN Conversion
17d73082cb This commit was manufactured by cvs2svn to create branch 'release_11'.
llvm-svn: 10440
2003-12-12 21:34:10 +00:00
1044 changed files with 26567 additions and 146334 deletions

View File

@@ -4,8 +4,8 @@ LLVM Release License
University of Illinois/NCSA
Open Source License
Copyright (c) 2003, 2004 University of Illinois at Urbana-Champaign.
All rights reserved.
Copyright (c) 2003, University of Illinois at Urbana-Champaign. All rights
reserved.
Developed by:
@@ -49,48 +49,3 @@ The LLVM software contains code written by third parties. Such software will
have its own individual LICENSE.TXT file in the directory in which it appears.
This file will describe the copyrights, license, and restrictions which apply
to that code.
The disclaimer of warranty in the University of Illinois Open Source License
applies to all code in the LLVM Distribution, and nothing in any of the
other licenses gives permission to use the names of the LLVM Team or the
University of Illinois to endorse or promote products derived from this
Software.
The following pieces of software have additional or alternate copyrights,
licenses, and/or restrictions:
Program Directory
------- ---------
Autoconf: llvm/autoconf
llvm/projects/ModuleMaker/autoconf
llvm/projects/sample/autoconf
Burg: llvm/utils/Burg
llvm/test/Programs/MultiSource/Applications/Burg
Aha: llvm/test/Programs/MultiSource/Applications/aha
SGEFA: llvm/test/Programs/MultiSource/Applications/sgefa
SIOD: llvm/test/Programs/MultiSource/Applications/siod
D: llvm/test/Programs/MultiSource/Applications/d
Lambda: llvm/test/Programs/MultiSource/Applications/lambda-0.1.3
hbd: llvm/test/Programs/MultiSource/Applications/hbd
Fhourstones: llvm/test/Programs/MultiSource/Benchmarks/Fhourstones
McCat: llvm/test/Programs/MultiSource/Benchmarks/McCat
Olden: llvm/test/Programs/MultiSource/Benchmarks/Olden
OptimizerEval: llvm/test/Programs/MultiSource/Benchmarks/OptimizerEval
Ptrdist: llvm/test/Programs/MultiSource/Benchmarks/Ptrdist
LLUBenchmark: llvm/test/Programs/MultiSource/Benchmarks/llubenchmark
SIM: llvm/test/Programs/MultiSource/Benchmarks/sim
cfrac: llvm/test/Programs/MultiSource/Benchmarks/MallocBench/cfrac
espresso: llvm/test/Programs/MultiSource/Benchmarks/MallocBench/espresso
gs: llvm/test/Programs/MultiSource/Benchmarks/MallocBench/gs
p2c: llvm/test/Programs/MultiSource/Benchmarks/MallocBench/p2c
gawk: llvm/test/Programs/MultiSource/Benchmarks/MallocBench/gawk
make: llvm/test/Programs/MultiSource/Benchmarks/MallocBench/make
perl: llvm/test/Programs/MultiSource/Benchmarks/MallocBench/perl
Dhrystone: llvm/test/Programs/SingleSource/Benchmarks/Dhrystone
SingleSource Tests: llvm/test/Programs/SingleSource/Benchmarks/Misc
llvm/test/Programs/SingleSource/CustomChecked
llvm/test/Programs/SingleSource/Gizmos
GNU Libc: llvm/runtime/GCCLibraries/libc
Zlib Library: llvm/runtime/zlib
PNG Library: llvm/runtime/libpng

View File

@@ -7,13 +7,9 @@
#
##===----------------------------------------------------------------------===##
LEVEL = .
DIRS = lib/Support utils lib tools
DIRS = lib/Support utils lib tools runtime
OPTIONAL_DIRS = projects
ifneq ($(MAKECMDGOALS),tools-only)
DIRS += runtime
endif
include $(LEVEL)/Makefile.common
test :: all
@@ -26,27 +22,25 @@ distclean:: clean
$(LEVEL)/config.log \
$(LEVEL)/TAGS
tools-only: all
tools-only:
@for dir in lib/Support utils lib tools; do $(MAKE) -C $$dir; done
AUTOCONF = autoconf
AUTOHEADER = autoheader
configure: autoconf/configure.ac autoconf/aclocal.m4
cd autoconf && $(AUTOCONF) -o ../configure configure.ac
include/Config/config.h.in: autoconf/configure.ac autoconf/aclocal.m4
$(AUTOHEADER) -I autoconf autoconf/configure.ac
# Install support for llvm include files.
# Install support for llvm include files:
.PHONY: install-includes
install-includes:
$(MKDIR) $(DESTDIR)$(includedir)/llvm
cd include && find * '!' '(' -name '*~' -o -name .cvsignore ')' -print | grep -v CVS | pax -rwdvpe $(DESTDIR)$(includedir)/llvm
ifneq ($(BUILD_SRC_ROOT),$(BUILD_OBJ_ROOT))
cd $(BUILD_SRC_ROOT)/include && find * '!' '(' -name '*~' -o -name .cvsignore ')' -print | grep -v CVS | pax -rwdvpe $(DESTDIR)$(includedir)/llvm
endif
$(MKDIR) $(includedir)/llvm
cd include && find * '!' '(' -name '*~' -o -name .cvsignore ')' -print | grep -v CVS | pax -rwdvpe $(includedir)/llvm
install:: install-includes
# Build tags database for Emacs/Xemacs:
.PHONY: tags
TAGS: tags
all:: tags
tags:
$(ETAGS) $(ETAGSFLAGS) `find $(wildcard $(SourceDir)/include $(SourceDir)/lib $(SourceDir)/tools) -name '*.cpp' -o -name '*.h'`

View File

@@ -2,78 +2,102 @@
#
# This file is included by Makefile.common. It defines paths and other
# values specific to a particular installation of LLVM.
#
#===-----------------------------------------------------------------------====
#
# Target operating system for which LLVM will be compiled.
#
OS=@OS@
#
# Target hardware architecture
#
ARCH=@ARCH@
# Endian-ness of the target
ENDIAN=@ENDIAN@
# Path to the C++ compiler to use. This is an optional setting, which defaults
# to whatever your gmake defaults to.
#
# Under Linux, for some reason the compiler driver wants to search the PATH to
# find the system assembler, which breaks if the LLVM assembler is in our path.
# Hack it to use the assembler in /usr/bin directly.
#
CXX = @CXX@
# We have the same problem with the CC binary, which use used by testcases for
# native builds.
#
CC := @CC@
# Linker flags.
#
# Compilation flags for the C and C++ compilers.
#
#
# Removing the compiler flags for now. They interfere with the test suite
# (which has its own autoconf stuff), and we don't use -DHAVE_CONFIG_H anyway.
#
#CPPFLAGS+=@DEFS@
#CCFLAGS+=@DEFS@
LDFLAGS+=@LDFLAGS@
#
# Removed since it prevents the tests from working properly.
#
#LIBS+=@LIBS@
#
# Libraries needed by tools
#
TOOLLINKOPTS=@LIBS@
# Path to the library archiver program.
#
# Path to the archiver program.
#
AR_PATH = @AR@
#
# The pathnames of the Flex and Bison programs, respectively.
YACC = @YACC@
BISON = @BISON@
#
BISON = @YACC@
FLEX = @LEX@
#
# Paths to miscellaneous programs.
RPWD = pwd
SED = sed
RM = rm
ECHO = echo
#
RPWD = @RPWD@
SED = @SED@
RM = @RM@
ECHO = @ECHO@
MKDIR = @abs_top_srcdir@/autoconf/mkinstalldirs
DATE = date
MV = mv
DATE = @DATE@
MV = @MV@
INSTALL = @INSTALL@
DOT = @DOT@
ETAGS = @ETAGS@
ETAGSFLAGS = @ETAGSFLAGS@
#
# Determine the target for which LLVM should generate code.
#
LLVMGCCARCH := @target@/3.4-llvm
# Full pathnames of LLVM C/C++ front-end 'cc1' and 'cc1plus' binaries:
LCC1 = @LLVMCC1@
LCC1XX = @LLVMCC1PLUS@
# Path to directory where object files should be stored during a build.
# Set OBJ_ROOT to "." if you do not want to use a separate place for
# object files.
#
#OBJ_ROOT = .
OBJ_ROOT := .
# Path to location for LLVM C/C++ front-end. You can modify this if you
# want to override the value set by configure.
# Path to location for LLVM front-end this should only be specified here if you
# want to override the value set in Makefile.$(uname)
#
LLVMGCCDIR := @LLVMGCCDIR@
# When this variable is set to 1, programs in the llvm/test/Programs hierarchy
# When this setting is set to true, programs in the llvm/test/Programs hierarchy
# are not recompiled from source code. Instead, the bytecode for the file is
# pulled from the BYTECODE_REPOSITORY directory. This can be useful when disk
# space is limited or when you just don't want to spend time running the C
# frontend.
#
#USE_PRECOMPILED_BYTECODE := 1
@UPB@
@@ -81,51 +105,71 @@ LLVMGCCDIR := @LLVMGCCDIR@
# versions of the test/Programs/* programs. This is used as the bytecode source
# when USE_PRECOMPILED_BYTECODE is specified or when source code is not
# available for the program (such as SPEC).
#
BYTECODE_REPOSITORY := @BCR@
# Path to location for purify, this is only needed if you build with
# ENABLE_PURIFY=1
#
PURIFY = @PURIFY@
#
# SPEC benchmarks:
# If these are set then run the SPEC benchmarks.
# Set the USE_SPEC variable to enable the use of the SPEC benchmarks.
# You must provide the SPEC benchmarks on your own.
@USE_SPEC2000@
@USE_SPEC95@
#
@USE_SPEC@
# Path to the SPEC benchmarks.
SPEC2000_ROOT := @SPEC2000_ROOT@
SPEC95_ROOT := @SPEC95_ROOT@
# Path to the Povray source code.
@USE_POVRAY@
POVRAY_ROOT := @POVRAY_ROOT@
#
# Path to the SPEC benchmarks. If you have the SPEC benchmarks, place the
# path here.
#
#SPEC_ROOT := /home/vadve/shared/benchmarks/speccpu2000/benchspec
SPEC_ROOT := @SPEC_ROOT@
#
# Path to the PAPI code. This is used by the reoptimizer only.
#
#PAPIDIR := /home/vadve/shared/papi-2.3.4.1
PAPIDIR := @PAPIDIR@
# These are options that can either be enabled here, or can be enabled on the
# make command line (ie, make ENABLE_PROFILING=1):
# make command line (ie, make ENABLE_PROFILING=1)
#
# When ENABLE_OPTIMIZED is enabled, Release builds of all of the LLVM code are
# turned on, and Debug builds are turned off.
#
#ENABLE_OPTIMIZED = 1
@ENABLE_OPTIMIZED@
# When ENABLE_PROFILING is enabled, the llvm source base is built with profile
# information to allow gprof to be used to get execution frequencies.
#
#ENABLE_PROFILING = 1
#
# This option tells the Makefiles to produce verbose output.
# It essentially prints the commands that make is executing
#
#VERBOSE = 1
# When ENABLE_PURIFY is set to 1, the LLVM tools are linked with purify (which
# must be locally installed) to allow for some automated memory error debugging.
#
#ENABLE_PURIFY = 1
@ENABLE_PURIFY@
#
# Enable JIT for this platform
#
@JIT@
#
# Disable LLC diffs for testing.
#
@DISABLE_LLC_DIFFS@
# Shared library extension for this platform.
SHLIBEXT = @SHLIBEXT@
###########################################################################
# Directory Configuration
# This section of the Makefile determines what is where. To be
@@ -142,27 +186,37 @@ SHLIBEXT = @SHLIBEXT@
#
###########################################################################
#
# Set the object build directory. By default, it is the current directory.
#
ifndef BUILD_OBJ_DIR
BUILD_OBJ_DIR := $(subst //,/,$(shell $(RPWD)))
endif
#
# Set the root of the object directory.
#
ifndef BUILD_OBJ_ROOT
BUILD_OBJ_ROOT := $(subst //,/,$(shell cd $(BUILD_OBJ_DIR)/$(LEVEL); $(RPWD)))
endif
#
# Set the source build directory. That is almost always the current directory.
#
ifndef BUILD_SRC_DIR
BUILD_SRC_DIR := $(subst //,/,@abs_top_srcdir@/$(patsubst $(BUILD_OBJ_ROOT)%,%,$(BUILD_OBJ_DIR)))
endif
#
# Set the source root directory.
#
ifndef BUILD_SRC_ROOT
BUILD_SRC_ROOT := $(subst //,/,@abs_top_srcdir@)
endif
#
# Set the LLVM object directory.
#
ifndef LLVM_OBJ_ROOT
ifdef LLVM_SRC_ROOT
LLVM_OBJ_ROOT := $(shell cd $(LLVM_SRC_ROOT); $(RPWD))
@@ -171,18 +225,23 @@ LLVM_OBJ_ROOT := $(BUILD_OBJ_ROOT)
endif
endif
#
# Set the LLVM source directory.
# It is typically the root directory of what we're compiling now.
#
ifndef LLVM_SRC_ROOT
LLVM_SRC_ROOT := $(BUILD_SRC_ROOT)
endif
#
# Set SourceDir for backwards compatbility.
#
ifndef SourceDir
SourceDir=$(BUILD_SRC_DIR)
endif
# Installation directories, as provided by the configure script.
exec_prefix = @exec_prefix@
prefix = @prefix@
program_transform_name = @program_transform_name@
@@ -194,7 +253,6 @@ sysconfdir = @sysconfdir@
sharedstatedir = @sharedstatedir@
localstatedir = @localstatedir@
libdir = @libdir@
bytecode_libdir = $(LLVMGCCDIR)/bytecode-libs
includedir = @includedir@
infodir = @infodir@
mandir = @mandir@

View File

@@ -71,14 +71,12 @@ all::$(LLVM_OBJ_ROOT)/config.status
ifdef SHARED_LIBRARY
# if SHARED_LIBRARY is specified, the default is to build the dynamic lib
all:: dynamic
install:: install-dynamic-library
endif
ifdef BYTECODE_LIBRARY
# if BYTECODE_LIBRARY is specified, the default is to build the bytecode lib
all:: bytecodelib
install:: install-bytecode-library
install-bytecode:: install-bytecode-library
install:: bytecodelib-install
endif
# Default Rule: Make sure it's also a :: rule
@@ -93,9 +91,6 @@ test::
# Default rule for building only bytecode.
bytecode::
# Default rule for installing only bytecode.
install-bytecode::
# Print out the directories used for building
prdirs::
@${ECHO} "Build Source Root: " $(BUILD_SRC_ROOT)
@@ -113,7 +108,7 @@ prdirs::
###########################################################################
.SUFFIXES:
.SUFFIXES: .c .cpp .h .hpp .y .l
.SUFFIXES: .lo .o .a $(SHLIBEXT) .bc .td
.SUFFIXES: .lo .o .a .so .bc .td
.SUFFIXES: .ps .dot .d
#
@@ -121,7 +116,7 @@ prdirs::
# slightly since GNU Make will not try to find implicit rules for targets
# which are marked as Phony.
#
.PHONY: all dynamic bytecodelib install-bytecode-library
.PHONY: all dynamic bytecodelib bytecodelib-install
.PHONY: clean distclean install test bytecode prdirs
###########################################################################
@@ -253,7 +248,9 @@ LGCCLDPROG := $(LLVMTOOLCURRENT)/gccld
# The LLVM GCC front-end in C and C++ flavors
#
LLVMGCC := PATH=$(LLVMTOOLCURRENT):$(PATH) $(LLVMGCCDIR)/bin/gcc
LCC1 := $(LLVMGCCDIR)/libexec/gcc/$(LLVMGCCARCH)/cc1
LLVMGXX := PATH=$(LLVMTOOLCURRENT):$(PATH) $(LLVMGCCDIR)/bin/g++
LCC1XX := $(LLVMGCCDIR)/libexec/gcc/$(LLVMGCCARCH)/cc1plus
#--------------------------------------------------------------------------
# Some of the compiled LLVM tools which are used for compilation of runtime
@@ -293,9 +290,6 @@ CPPFLAGS += -D_GNU_SOURCE
# Pull in limit macros from stdint.h, even in C++:
CPPFLAGS += -D__STDC_LIMIT_MACROS
### FIXME: this is GCC specific
CPPFLAGS += -DDEPRECATED='__attribute__ ((deprecated))'
CompileCommonOpts := -Wall -W -Wwrite-strings -Wno-unused
CompileOptimizeOpts := -O3 -DNDEBUG -finline-functions
@@ -359,7 +353,7 @@ Depend := $(CXX) -MM -I$(LEVEL)/include $(CPPFLAGS)
DependC := $(CC) -MM -I$(LEVEL)/include $(CPPFLAGS)
# Archive a bunch of .o files into a .a file...
AR = $(AR_PATH) cr
AR = ${AR_PATH} cq
#----------------------------------------------------------
@@ -369,8 +363,7 @@ AR = $(AR_PATH) cr
#
ifndef Source
Source := $(notdir $(ExtraSource) $(wildcard $(SourceDir)/*.cpp \
$(SourceDir)/*.cc $(SourceDir)/*.c $(SourceDir)/*.y \
$(SourceDir)/*.l))
$(SourceDir)/*.c $(SourceDir)/*.y $(SourceDir)/*.l))
endif
#
@@ -395,7 +388,7 @@ RObjectsG := $(addprefix $(BUILD_OBJ_DIR)/Debug/,$(RObjs))
#---------------------------------------------------------
ifdef DIRS
all install clean test bytecode stripped-bytecode install-bytecode::
all install clean test bytecode stripped-bytecode::
$(VERB) for dir in ${DIRS}; do \
if [ ! -f $$dir/Makefile ]; \
then \
@@ -414,9 +407,8 @@ clean :: $(addsuffix /.makeclean , $(PARALLEL_DIRS))
test :: $(addsuffix /.maketest , $(PARALLEL_DIRS))
bytecode :: $(addsuffix /.makebytecode, $(PARALLEL_DIRS))
stripped-bytecode :: $(addsuffix /.makestripped-bytecode, $(PARALLEL_DIRS))
install-bytecode :: $(addsuffix /.makeinstall-bytecode, $(PARALLEL_DIRS))
%/.makeall %/.makeinstall %/.makeclean %/.maketest %/.makebytecode %/.makestripped-bytecode %/.makeinstall-bytecode:
%/.makeall %/.makeinstall %/.makeclean %/.maketest %/.makebytecode %/.makestripped-bytecode:
$(VERB) if [ ! -f $(@D)/Makefile ]; \
then \
$(MKDIR) $(@D); \
@@ -427,7 +419,7 @@ endif
# Handle directories that may or may not exist
ifdef OPTIONAL_DIRS
all install clean test bytecode stripped-bytecode install-bytecode::
all install clean test bytecode stripped-bytecode::
$(VERB) for dir in ${OPTIONAL_DIRS}; do \
if [ -d $(SourceDir)/$$dir ]; \
then\
@@ -462,55 +454,44 @@ endif
# of it. For this reason, sometimes it's useful to use libraries as .a files.
###########################################################################
# Install rule for making bytecode library directory if it does not exist.
# Trigger this by making libraries that need to be installed here depend on it.
$(DESTDIR)$(bytecode_libdir):
$(MKDIR) $@
ifdef LIBRARYNAME
# Make sure there isn't any extranous whitespace on the LIBRARYNAME option
LIBRARYNAME := $(strip $(LIBRARYNAME))
LIBNAME_O := $(DESTLIBRELEASE)/lib$(LIBRARYNAME)$(SHLIBEXT)
LIBNAME_P := $(DESTLIBPROFILE)/lib$(LIBRARYNAME)$(SHLIBEXT)
LIBNAME_G := $(DESTLIBDEBUG)/lib$(LIBRARYNAME)$(SHLIBEXT)
LIBNAME_CUR := $(DESTLIBCURRENT)/lib$(LIBRARYNAME)$(SHLIBEXT)
LIBNAME_O := $(DESTLIBRELEASE)/lib$(LIBRARYNAME).so
LIBNAME_P := $(DESTLIBPROFILE)/lib$(LIBRARYNAME).so
LIBNAME_G := $(DESTLIBDEBUG)/lib$(LIBRARYNAME).so
LIBNAME_AO := $(DESTLIBRELEASE)/lib$(LIBRARYNAME).a
LIBNAME_AP := $(DESTLIBPROFILE)/lib$(LIBRARYNAME).a
LIBNAME_AG := $(DESTLIBDEBUG)/lib$(LIBRARYNAME).a
LIBNAME_ACUR := $(DESTLIBCURRENT)/lib$(LIBRARYNAME).a
LIBNAME_OBJO := $(DESTLIBRELEASE)/$(LIBRARYNAME).o
LIBNAME_OBJP := $(DESTLIBPROFILE)/$(LIBRARYNAME).o
LIBNAME_OBJG := $(DESTLIBDEBUG)/$(LIBRARYNAME).o
LIBNAME_OBJCUR := $(DESTLIBCURRENT)/$(LIBRARYNAME).o
LIBNAME_BC := $(DESTLIBBYTECODE)/lib$(LIBRARYNAME).bc
#--------------------------------------------------------------------
# Library Targets
# Modify the top level targets to build the desired libraries.
#--------------------------------------------------------------------
# dynamic target builds a shared object version of the library...
dynamic:: $(LIBNAME_CUR)
dynamic:: $(DESTLIBCURRENT)/lib$(LIBRARYNAME).so
bytecodelib:: $(LIBNAME_BC)
install-bytecode-library:: $(DESTDIR)$(bytecode_libdir)/lib$(LIBRARYNAME).bc
bytecodelib-install:: $(LLVMGCCDIR)/bytecode-libs/lib$(LIBRARYNAME).bc
$(DESTDIR)$(bytecode_libdir)/lib$(LIBRARYNAME).bc: $(LIBNAME_BC) $(DESTDIR)$(bytecode_libdir)
$(LLVMGCCDIR)/bytecode-libs/lib$(LIBRARYNAME).bc: $(LIBNAME_BC)
@${ECHO} ======= Installing $(LIBRARYNAME) bytecode library =======
cp $< $@
# Does the library want a .o version built?
ifndef DONT_BUILD_RELINKED
all:: $(LIBNAME_OBJCUR)
install:: install-single-object-library
all:: $(DESTLIBCURRENT)/$(LIBRARYNAME).o
endif
# Does the library want an archive version built?
ifdef BUILD_ARCHIVE
all:: $(LIBNAME_ACUR)
install:: install-archive-library
all:: $(DESTLIBCURRENT)/lib$(LIBRARYNAME).a
endif
#--------------------------------------------------------------------
@@ -555,10 +536,6 @@ $(LIBNAME_G): $(ObjectsG) $(LibSubDirs) $(DESTLIBDEBUG)/.dir
$(VERB) $(LIBTOOL) --mode=install $(INSTALL) $*.la $(DESTLIBCURRENT)
@${ECHO} ======= Finished building $(LIBRARYNAME) dynamic debug library =======
install-dynamic-library: $(LIBNAME_CUR)
$(MKDIR) $(DESTDIR)$(libdir)
$(VERB) $(LIBTOOL) --mode=install $(INSTALL) $(LIBNAME_CUR) $(DESTDIR)$(libdir)/lib$(LIBRARYNAME)$(SHLIBEXT)
#
# Rules for building static archive libraries.
#
@@ -580,9 +557,6 @@ $(LIBNAME_AG): $(ObjectsG) $(LibSubDirs) $(DESTLIBDEBUG)/.dir
$(VERB) $(Link) -g $(STRIP) -o $@ $(ObjectsG) $(LibSubDirs) -static
@${ECHO} ======= Finished building $(LIBRARYNAME) archive debug library =======
install-archive-library: $(LIBNAME_ACUR)
$(MKDIR) $(DESTDIR)$(libdir)
$(VERB) $(LIBTOOL) --mode=install $(INSTALL) $(LIBNAME_ACUR) $(DESTDIR)$(libdir)/lib$(LIBRARYNAME).a
#
# Rules for building .o libraries.
@@ -610,10 +584,23 @@ $(LIBNAME_OBJG): $(ObjectsG) $(LibSubDirs) $(DESTLIBDEBUG)/.dir
@${ECHO} "Linking `basename $@`"
$(VERB) $(Relink) -o $@ $(RObjectsG) $(LibSubDirs)
install-single-object-library: $(LIBNAME_OBJCUR)
$(MKDIR) $(DESTDIR)$(libdir)
$(VERB) $(LIBTOOL) --mode=install $(INSTALL) $(LIBNAME_OBJCUR) $(DESTDIR)$(libdir)/$(LIBRARYNAME).o
endif
#------------------------------------------------------------------------
# Create a TAGS database for emacs
#------------------------------------------------------------------------
ifneq ($(ETAGS),false)
ifeq ($(LEVEL), .)
SRCDIRS := $(wildcard $(SourceDir)/include $(SourceDir)/lib $(SourceDir)/tools)
tags:
$(ETAGS) -l c++ `find $(SRCDIRS) -name '*.cpp' -o -name '*.h'`
all:: tags
endif
else
tags:
${ECHO} "Cannot build $@: The program etags is not installed"
endif
#------------------------------------------------------------------------
@@ -694,8 +681,8 @@ $(TOOLEXENAME_P): $(ObjectsP) $(USED_LIB_PATHS_P) $(DESTTOOLPROFILE)/.dir
@${ECHO} ======= Finished building $(TOOLNAME) profile executable =======
install:: $(TOOLEXENAMES)
$(MKDIR) $(DESTDIR)$(bindir)
$(LIBTOOL) --mode=install $(INSTALL_PROGRAM) -c -m 0755 $(TOOLEXENAMES) $(DESTDIR)$(bindir)/$(TOOLNAME)
$(MKDIR) $(bindir)
$(LIBTOOL) --mode=install $(INSTALL_PROGRAM) -c -m 0755 $(TOOLEXENAMES) $(bindir)/$(TOOLNAME)
endif
@@ -809,10 +796,7 @@ clean::
$(VERB) $(RM) -rf $(BUILD_OBJ_DIR)/Debug $(BUILD_OBJ_DIR)/Release
$(VERB) $(RM) -rf $(BUILD_OBJ_DIR)/Profile $(BUILD_OBJ_DIR)/Depend
$(VERB) $(RM) -rf $(BUILD_OBJ_DIR)/BytecodeObj
$(VERB) $(RM) -f core core.[0-9][0-9]* *.o *.d *~ *.flc
ifneq ($(strip $(SHLIBEXT)),) # Extra paranoia - make real sure SHLIBEXT is set
$(VERB) $(RM) -f *$(SHLIBEXT)
endif
$(VERB) $(RM) -f core core.[0-9][0-9]* *.o *.d *.so *~ *.flc
$(VERB) $(RM) -f $(LEX_OUTPUT) $(YACC_OUTPUT)
###########################################################################

View File

@@ -1,21 +0,0 @@
#!/bin/sh
die () {
echo "$@" 1>&2
exit 1
}
test -d autoconf && test -f autoconf/configure.ac && cd autoconf
[ -f configure.ac ] || die "Can't find 'autoconf' dir; please cd into it first"
echo "Regenerating aclocal.m4 with aclocal"
aclocal || die "aclocal failed"
autoconf --version | egrep '2\.5[0-9]' > /dev/null
if test $? -ne 0
then
die "Your autoconf was not detected as being 2.5x"
fi
echo "Note: Warnings about 'AC_CONFIG_SUBDIRS: you should use literals' are ok"
echo "Regenerating configure with autoconf 2.5x"
autoconf -o ../configure configure.ac || die "autoconf failed"
cd ..
echo "Regenerating config.h.in with autoheader 2.5x"
autoheader -I autoconf autoconf/configure.ac || die "autoheader failed"
exit 0

View File

@@ -5888,8 +5888,10 @@ if test "$ac_cv_cxx_namespaces" = yes; then
fi
])
#
# Check for hash_map extension. This is from
# http://www.gnu.org/software/ac-archive/htmldoc/ac_cxx_have_ext_hash_map.html
#
AC_DEFUN([AC_CXX_HAVE_STD_EXT_HASH_MAP],
[AC_CACHE_CHECK([whether the compiler has <ext/hash_map> defining template class std::hash_map],
ac_cv_cxx_have_std_ext_hash_map,
@@ -5902,12 +5904,9 @@ using namespace std;
#endif],[hash_map<int, int> t;],
[ac_cv_cxx_have_std_ext_hash_map=yes], [ac_cv_cxx_have_std_ext_hash_map=no])
AC_LANG_RESTORE])
HAVE_STD_EXT_HASH_MAP=0
if test "$ac_cv_cxx_have_std_ext_hash_map" = yes
then
HAVE_STD_EXT_HASH_MAP=1
fi
AC_SUBST(HAVE_STD_EXT_HASH_MAP)])
if test "$ac_cv_cxx_have_std_ext_hash_map" = yes; then
AC_DEFINE(HAVE_STD_EXT_HASH_MAP,,[Define if the compiler has a header <ext/hash_map> that defines template class std::hash_map.])
fi])
AC_DEFUN([AC_CXX_HAVE_GNU_EXT_HASH_MAP],
[AC_CACHE_CHECK([whether the compiler has <ext/hash_map> defining template class __gnu_cxx::hash_map],
@@ -5921,12 +5920,9 @@ using namespace __gnu_cxx;
#endif],[hash_map<int,int> t; ],
[ac_cv_cxx_have_gnu_ext_hash_map=yes],[ac_cv_cxx_have_gnu_ext_hash_map=no])
AC_LANG_RESTORE])
HAVE_GNU_EXT_HASH_MAP=0
if test "$ac_cv_cxx_have_gnu_ext_hash_map" = yes
then
HAVE_GNU_EXT_HASH_MAP=1
fi
AC_SUBST(HAVE_GNU_EXT_HASH_MAP)])
if test "$ac_cv_cxx_have_gnu_ext_hash_map" = yes; then
AC_DEFINE(HAVE_GNU_EXT_HASH_MAP,,[Define if the compiler has a header <ext/hash_map> that defines template class __gnu_cxx::hash_map.])
fi])
AC_DEFUN([AC_CXX_HAVE_GLOBAL_HASH_MAP],
[AC_CACHE_CHECK([whether the compiler has <hash_map> defining template class ::hash_map],
@@ -5937,20 +5933,18 @@ AC_DEFUN([AC_CXX_HAVE_GLOBAL_HASH_MAP],
AC_TRY_COMPILE([#include <hash_map>],[hash_map<int,int> t; ],
[ac_cv_cxx_have_global_hash_map=yes], [ac_cv_cxx_have_global_hash_map=no])
AC_LANG_RESTORE])
HAVE_GLOBAL_HASH_MAP=0
if test "$ac_cv_cxx_have_global_hash_map" = yes
then
HAVE_GLOBAL_HASH_MAP=1
fi
AC_SUBST(HAVE_GLOBAL_HASH_MAP)])
if test "$ac_cv_cxx_have_global_hash_map" = yes; then
AC_DEFINE(HAVE_GLOBAL_HASH_MAP,,[Define if the compiler has a header <hash_map> that defines template class ::hash_map.])
fi])
AC_DEFUN([AC_CXX_HAVE_HASH_MAP],
[AC_CXX_HAVE_STD_EXT_HASH_MAP
AC_CXX_HAVE_GNU_EXT_HASH_MAP
AC_CXX_HAVE_GLOBAL_HASH_MAP])
#
# Check for hash_set extension. This is modified from
# http://www.gnu.org/software/ac-archive/htmldoc/ac_cxx_have_ext_hash_set.html
#
AC_DEFUN([AC_CXX_HAVE_STD_EXT_HASH_SET],
[AC_CACHE_CHECK([whether the compiler has <ext/hash_set> defining template class std::hash_set],
ac_cv_cxx_have_std_ext_hash_set,
@@ -5963,12 +5957,9 @@ using namespace std;
#endif],[hash_set<int> t; ],
[ac_cv_cxx_have_std_ext_hash_set=yes], [ac_cv_cxx_have_std_ext_hash_set=no])
AC_LANG_RESTORE])
HAVE_STD_EXT_HASH_SET=0
if test "$ac_cv_cxx_have_std_ext_hash_set" = yes
then
HAVE_STD_EXT_HASH_SET=1
fi
AC_SUBST(HAVE_STD_EXT_HASH_SET)])
if test "$ac_cv_cxx_have_std_ext_hash_set" = yes; then
AC_DEFINE(HAVE_STD_EXT_HASH_SET,,[Define if the compiler has a header <ext/hash_set> that defines template class std::hash_set.])
fi])
AC_DEFUN([AC_CXX_HAVE_GNU_EXT_HASH_SET],
[AC_CACHE_CHECK(
@@ -5983,12 +5974,9 @@ using namespace __gnu_cxx;
#endif],[hash_set<int> t; ],
[ac_cv_cxx_have_gnu_ext_hash_set=yes], [ac_cv_cxx_have_gnu_ext_hash_set=no])
AC_LANG_RESTORE])
HAVE_GNU_EXT_HASH_SET=0
if test "$ac_cv_cxx_have_gnu_ext_hash_set" = yes
then
HAVE_GNU_EXT_HASH_SET=1
fi
AC_SUBST(HAVE_GNU_EXT_HASH_SET)])
if test "$ac_cv_cxx_have_gnu_ext_hash_set" = yes; then
AC_DEFINE(HAVE_GNU_EXT_HASH_SET,,[Define if the compiler has a header <ext/hash_set> that defines template class __gnu_cxx::hash_set.])
fi])
AC_DEFUN([AC_CXX_HAVE_GLOBAL_HASH_SET],
[AC_CACHE_CHECK([whether the compiler has <hash_set> defining template class ::hash_set],
@@ -5999,20 +5987,19 @@ AC_DEFUN([AC_CXX_HAVE_GLOBAL_HASH_SET],
AC_TRY_COMPILE([#include <hash_set>],[hash_set<int> t; return 0;],
[ac_cv_cxx_have_global_hash_set=yes], [ac_cv_cxx_have_global_hash_set=no])
AC_LANG_RESTORE])
HAVE_GLOBAL_HASH_SET=0
if test "$ac_cv_cxx_have_global_hash_set" = yes
then
HAVE_GLOBAL_HASH_SET=1
fi
AC_SUBST(HAVE_GLOBAL_HASH_SET)])
if test "$ac_cv_cxx_have_global_hash_set" = yes; then
AC_DEFINE(HAVE_GLOBAL_HASH_SET,,[Define if the compiler has a header <hash_set> that defines template class ::hash_set.])
fi])
AC_DEFUN([AC_CXX_HAVE_HASH_SET],
[AC_CXX_HAVE_STD_EXT_HASH_SET
AC_CXX_HAVE_GNU_EXT_HASH_SET
AC_CXX_HAVE_GLOBAL_HASH_SET])
#
# Check for standard iterator extension. This is modified from
# http://www.gnu.org/software/ac-archive/htmldoc/ac_cxx_have_ext_hash_set.html
#
AC_DEFUN([AC_CXX_HAVE_STD_ITERATOR],
[AC_CACHE_CHECK(whether the compiler has the standard iterator,
ac_cv_cxx_have_std_iterator,
@@ -6026,12 +6013,10 @@ using namespace std;
ac_cv_cxx_have_std_iterator=yes, ac_cv_cxx_have_std_iterator=no)
AC_LANG_RESTORE
])
HAVE_STD_ITERATOR=0
if test "$ac_cv_cxx_have_std_iterator" = yes
then
HAVE_STD_ITERATOR=1
if test "$ac_cv_cxx_have_std_iterator" = yes; then
AC_DEFINE(HAVE_STD_ITERATOR,,[define if the compiler has STL iterators])
fi
AC_SUBST(HAVE_STD_ITERATOR)])
])
#
# Check for bidirectional iterator extension. This is modified from
@@ -6050,15 +6035,15 @@ using namespace std;
ac_cv_cxx_have_bi_iterator=yes, ac_cv_cxx_have_bi_iterator=no)
AC_LANG_RESTORE
])
HAVE_BI_ITERATOR=0
if test "$ac_cv_cxx_have_bi_iterator" = yes
then
HAVE_BI_ITERATOR=1
if test "$ac_cv_cxx_have_bi_iterator" = yes; then
AC_DEFINE(HAVE_BI_ITERATOR,,[define if the compiler has bidirectional iterator])
fi
AC_SUBST(HAVE_BI_ITERATOR)])
])
#
# Check for forward iterator extension. This is modified from
# http://www.gnu.org/software/ac-archive/htmldoc/ac_cxx_have_ext_hash_set.html
#
AC_DEFUN([AC_CXX_HAVE_FWD_ITERATOR],
[AC_CACHE_CHECK(whether the compiler has forward iterators,
ac_cv_cxx_have_fwd_iterator,
@@ -6072,12 +6057,41 @@ using namespace std;
ac_cv_cxx_have_fwd_iterator=yes, ac_cv_cxx_have_fwd_iterator=no)
AC_LANG_RESTORE
])
HAVE_FWD_ITERATOR=0
if test "$ac_cv_cxx_have_fwd_iterator" = yes
then
HAVE_FWD_ITERATOR=1
if test "$ac_cv_cxx_have_fwd_iterator" = yes; then
AC_DEFINE(HAVE_FWD_ITERATOR,,[define if the compiler has STL iterators])
fi
AC_SUBST(HAVE_FWD_ITERATOR)])
])
#
# Check for slist extension. This is from
# http://www.gnu.org/software/ac-archive/htmldoc/ac_cxx_have_ext_slist.html
#
AC_DEFUN([AC_CXX_HAVE_EXT_SLIST],
[AC_CACHE_CHECK(whether the compiler has ext/slist,
ac_cv_cxx_have_ext_slist,
[AC_REQUIRE([AC_CXX_NAMESPACES])
AC_LANG_SAVE
AC_LANG_CPLUSPLUS
AC_TRY_COMPILE([#include <ext/slist>
#ifdef HAVE_NAMESPACES
using namespace std;
#endif],[slist<int> s; return 0;],
ac_cv_cxx_have_ext_slist=std, ac_cv_cxx_have_ext_slist=no)
AC_TRY_COMPILE([#include <ext/slist>
#ifdef HAVE_NAMESPACES
using namespace __gnu_cxx;
#endif],[slist<int> s; return 0;],
ac_cv_cxx_have_ext_slist=gnu, ac_cv_cxx_have_ext_slist=no)
AC_LANG_RESTORE
])
if test "$ac_cv_cxx_have_ext_slist" = std; then
AC_DEFINE(HAVE_EXT_SLIST,std,[define if the compiler has ext/slist])
fi
if test "$ac_cv_cxx_have_ext_slist" = gnu; then
AC_DEFINE(HAVE_EXT_SLIST,gnu,[define if the compiler has ext/slist])
fi
])
#
# Check for FLEX. This is modified from
@@ -6097,10 +6111,6 @@ fi
# Check for Bison. This is modified from
# http://www.gnu.org/software/ac-archive/htmldoc/ac_cxx_namespaces.html
#
# This macro verifies that Bison is installed. If successful, then
# 1) YACC is set to bison -y (to emulate YACC calls)
# 2) BISON is set to bison
#
AC_DEFUN([AC_PROG_BISON],
[AC_CACHE_CHECK(,
ac_cv_has_bison,
@@ -6109,7 +6119,7 @@ ac_cv_has_bison,
if test "$YACC" != "bison -y"; then
AC_MSG_ERROR([bison not found but required])
else
AC_SUBST(BISON,[bison],[location of bison])
AC_SUBST(YACC,[bison],[location of bison])
fi
])

View File

@@ -1,4 +1,20 @@
dnl Initialize autoconf
dnl Autoconf requirements
dnl AC_INIT(package, version, bug-report-address)
dnl information on the package
dnl checks for programs
dnl checks for libraries
dnl checks for header files
dnl checks for types
dnl checks for structures
dnl checks for compiler characteristics
dnl checks for library functions
dnl checks for system services
dnl AC_CONFIG_FILES([file...])
dnl AC_OUTPUT
dnl **************************************************************************
dnl * Initialize
dnl **************************************************************************
AC_INIT([[[LLVM]]],[[[1.1]]],[llvmbugs@cs.uiuc.edu])
dnl Place all of the extra autoconf files into the config subdirectory
@@ -14,7 +30,9 @@ then
fi
fi
dnl
dnl Configure all of the projects present in our source tree.
dnl
for i in `ls ${srcdir}/projects`
do
if test ${i} != "CVS"
@@ -40,6 +58,7 @@ AC_CONFIG_MAKEFILE(test/Programs/Makefile)
AC_CONFIG_MAKEFILE(test/Programs/Makefile.programs)
AC_CONFIG_MAKEFILE(test/Programs/TEST.aa.Makefile)
AC_CONFIG_MAKEFILE(test/Programs/TEST.dsgraph.report)
AC_CONFIG_MAKEFILE(test/Programs/TEST.micro.report)
AC_CONFIG_MAKEFILE(test/Programs/TEST.aa.report)
AC_CONFIG_MAKEFILE(test/Programs/TEST.example.Makefile)
AC_CONFIG_MAKEFILE(test/Programs/TEST.nightly.Makefile)
@@ -50,12 +69,10 @@ AC_CONFIG_MAKEFILE(test/Programs/TEST.dsgraph.Makefile)
AC_CONFIG_MAKEFILE(test/Programs/TEST.jit.report)
AC_CONFIG_MAKEFILE(test/Programs/TEST.typesafe.Makefile)
AC_CONFIG_MAKEFILE(test/Programs/TEST.dsgraph.gnuplot)
AC_CONFIG_MAKEFILE(test/Programs/TEST.vtl.Makefile)
AC_CONFIG_MAKEFILE(test/Programs/TEST.micro.Makefile)
AC_CONFIG_MAKEFILE(test/Programs/External/Makefile)
AC_CONFIG_MAKEFILE(test/Programs/External/SPEC/Makefile)
AC_CONFIG_MAKEFILE(test/Programs/External/SPEC/Makefile.spec)
AC_CONFIG_MAKEFILE(test/Programs/External/SPEC/Makefile.spec2000)
AC_CONFIG_MAKEFILE(test/Programs/External/SPEC/Makefile.spec95)
AC_CONFIG_MAKEFILE(test/Programs/MultiSource/Makefile)
AC_CONFIG_MAKEFILE(test/Programs/MultiSource/Makefile.multisrc)
AC_CONFIG_MAKEFILE(test/Programs/MultiSource/Benchmarks/FreeBench/analyzer/test.in)
@@ -73,12 +90,15 @@ AC_CONFIG_MAKEFILE(test/Programs/MultiSource/Benchmarks/FreeBench/pifft/Makefile
AC_CONFIG_MAKEFILE(test/Programs/MultiSource/Benchmarks/FreeBench/pifft/test.in)
AC_CONFIG_MAKEFILE(test/Programs/SingleSource/Makefile)
AC_CONFIG_MAKEFILE(test/Programs/SingleSource/Makefile.singlesrc)
AC_CONFIG_MAKEFILE(test/Programs/SingleSource/UnitTests/SetjmpLongjmp/Makefile)
AC_CONFIG_MAKEFILE(tools/Makefile)
AC_CONFIG_MAKEFILE(utils/Makefile)
AC_CONFIG_MAKEFILE(projects/Makefile)
dnl Find the install program (needs to be done before canonical stuff)
dnl **************************************************************************
dnl * Determine which system we are building on
dnl **************************************************************************
dnl Check the install program (needs to be done before canonical stuff)
AC_PROG_INSTALL
dnl Check which host for which we're compiling. This will tell us which LLVM
@@ -134,6 +154,10 @@ case $target in
;;
esac
dnl **************************************************************************
dnl * Check for programs.
dnl **************************************************************************
dnl Check for compilation tools
AC_PROG_CXX
AC_PROG_CC(gcc)
@@ -144,6 +168,7 @@ if test "$GCC" != "yes"
then
AC_MSG_ERROR([gcc required but not found])
fi
if test "$GXX" != "yes"
then
AC_MSG_ERROR([g++ required but not found])
@@ -153,41 +178,86 @@ dnl Verify that GCC is version 3.0 or higher
gccmajor=`$CC --version | head -n 1 | awk '{print $NF;}' | cut -d. -f1`
if test "$gccmajor" -lt "3"
then
AC_MSG_ERROR([gcc 3.x required, but you have a lower version])
AC_MSG_ERROR([gcc 3.x required])
fi
dnl Check for GNU Make. We use its extensions too, so don't build without it
dnl Check for GNU Make. We use its extensions to, so don't build without it
CHECK_GNU_MAKE
if test -z "$_cv_gnu_make_command"
then
AC_MSG_ERROR([GNU Make required but not found])
fi
dnl Checks for other tools
dnl Check for compiler-compiler tools (reminds me of Little Caesar's Pizza)
AC_PROG_FLEX
AC_PROG_BISON
dnl Check for libtool
AC_PROG_LIBTOOL
dnl Checks for tools we can get away with not having:
AC_PATH_PROG(DOT,[dot],[true dot])
AC_PATH_PROG(ETAGS,[etags],[true etags])
dnl Check if we know how to tell etags we are using C++:
etags_version=`$ETAGS --version 2>&1`
case "$etags_version" in
*[Ee]xuberant*) ETAGSFLAGS="--language-force=c++" ;;
*GNU\ Emacs*) ETAGSFLAGS="-l c++" ;;
*) ETAGSFLAGS="" ;;
esac
AC_SUBST(ETAGSFLAGS,$ETAGSFLAGS)
AC_PATH_PROG(PYTHON,[python],[true python])
if test "$PYTHON" = "false"
dnl Check for our special programs
AC_PATH_PROG(RPWD,[pwd],[false])
if test ${RPWD} = "false"
then
AC_MSG_WARN([Python is required for the test suite, but it was not found])
AC_MSG_ERROR([pwd required but not found])
fi
AC_PATH_PROG(QMTEST,[qmtest],[true qmtest])
if test "$QMTEST" = "false"
AC_PATH_PROG(AR,[ar],[false])
if test ${AR} = "false"
then
AC_MSG_WARN([QMTest is required for the test suite, but it was not found])
AC_MSG_ERROR([ar required but not found])
fi
AC_PATH_PROG(SED,[sed],[false])
if test ${SED} = "false"
then
AC_MSG_ERROR([sed required but not found])
fi
AC_PATH_PROG(RM,[rm],[false])
if test ${RM} = "false"
then
AC_MSG_ERROR([rm required but not found])
fi
AC_PATH_PROG(ECHO,[echo],[false])
if test ${ECHO} = "false"
then
AC_MSG_ERROR([echo required but not found])
fi
AC_PATH_PROG(MKDIR,[mkdir],[false])
if test ${MKDIR} = "false"
then
AC_MSG_ERROR([mkdir required but not found])
fi
AC_PATH_PROG(DATE,[date],[false])
if test ${DATE} = "false"
then
AC_MSG_ERROR([date required but not found])
fi
AC_PATH_PROG(MV,[mv],[false])
if test ${MV} = "false"
then
AC_MSG_ERROR([mv required but not found])
fi
AC_PATH_PROG(DOT,[dot],[false])
AC_PATH_PROG(ETAGS,[etags],[false])
AC_PATH_PROG(PYTHON,[python],[false])
if test ${PYTHON} = "false"
then
AC_MSG_WARN([python required but not found])
fi
AC_PATH_PROG(QMTEST,[qmtest],[false])
if test ${QMTEST} = "false"
then
AC_MSG_WARN([qmtest required but not found])
fi
dnl Verify that the version of python available is high enough for qmtest
@@ -201,17 +271,20 @@ then
then
if test "$pyminor" -lt "2"
then
AC_MSG_WARN([QMTest requires Python 2.2 or later])
AC_MSG_WARN([Python 2.2 or greater required for qmtest])
fi
fi
else
AC_MSG_WARN([QMTest requires Python 2.2 or later])
AC_MSG_WARN([Python 2.2 or greater required for qmtest])
fi
dnl Verify that the source directory is valid
AC_CONFIG_SRCDIR(["Makefile.config.in"])
dnl Checks for libraries:
dnl **************************************************************************
dnl * Check for libraries.
dnl **************************************************************************
dnl libelf is for sparc only; we can ignore it if we don't have it
AC_CHECK_LIB(elf, elf_begin)
@@ -223,29 +296,46 @@ AC_SEARCH_LIBS(mallinfo,malloc,AC_DEFINE([HAVE_MALLINFO],[1],[Define if mallinfo
dnl pthread locking functions are optional - but llvm will not be thread-safe
dnl without locks.
AC_SEARCH_LIBS(pthread_mutex_lock,pthread,HAVE_PTHREAD_MUTEX_LOCK=1,HAVE_PTHREAD_MUTEX_LOCK=0)
AC_SUBST(HAVE_PTHREAD_MUTEX_LOCK)
AC_SEARCH_LIBS(pthread_mutex_lock,pthread,AC_DEFINE(HAVE_PTHREAD_MUTEX_LOCK,1,[Define if PThread mutexes (e.g., pthread_mutex_lock) are available in the system's thread library.]))
dnl Checks for header files.
dnl We don't check for ancient stuff or things that are guaranteed to be there
dnl by the C++ standard. We always use the <cfoo> versions of <foo.h> C headers.
dnl
dnl The math libraries are used by the test code, but not by the actual LLVM
dnl code.
dnl
dnl AC_CHECK_LIB(m, cos)
dnl **************************************************************************
dnl * Checks for header files.
dnl * Chances are, if the standard C or POSIX type header files are missing,
dnl * then LLVM just isn't going to compile. However, it is possible that
dnl * the necessary functions/macros will be included from other
dnl * (non-standard and non-obvious) header files.
dnl *
dnl * So, we'll be gracious, give it a chance, and try to go on without
dnl * them.
dnl **************************************************************************
AC_HEADER_STDC
AC_HEADER_SYS_WAIT
dnl Checks for POSIX and other various system-specific header files
AC_CHECK_HEADERS(fcntl.h limits.h sys/time.h unistd.h malloc.h sys/mman.h sys/resource.h dlfcn.h link.h execinfo.h)
dnl Check for ANSI C/POSIX header files
AC_CHECK_HEADERS(assert.h fcntl.h limits.h sys/time.h unistd.h errno.h signal.h math.h)
dnl Check for things that need to be included in public headers, and so
dnl for which we may not have access to a HAVE_* preprocessor #define.
dnl (primarily used in DataTypes.h)
AC_CHECK_HEADER([sys/types.h],
[INCLUDE_SYS_TYPES_H='#include <sys/types.h>'],
[INCLUDE_SYS_TYPES_H=''])
AC_SUBST(INCLUDE_SYS_TYPES_H)
AC_CHECK_HEADER([inttypes.h],
[INCLUDE_INTTYPES_H='#include <inttypes.h>'],
[INCLUDE_INTTYPES_H=''])
AC_SUBST(INCLUDE_INTTYPES_H)
dnl Check for system specific header files
AC_CHECK_HEADERS(malloc.h sys/mman.h sys/resource.h)
dnl Check for header files associated with dlopen and friends
AC_CHECK_HEADERS(dlfcn.h link.h)
dnl **************************************************************************
dnl * Checks for typedefs, structures, and compiler characteristics.
dnl **************************************************************************
dnl Check for const and inline keywords
AC_C_CONST
AC_C_INLINE
dnl Check for machine endian-ness
AC_C_BIGENDIAN(AC_DEFINE([ENDIAN_BIG],[],[Define if the machine is Big-Endian]),AC_DEFINE([ENDIAN_LITTLE],[],[Define if the machine is Little-Endian]))
dnl Check for types
AC_TYPE_PID_T
@@ -258,38 +348,62 @@ AC_STRUCT_TM
dnl Check for various C features
AC_C_PRINTF_A
dnl Check for the endianness of the target
AC_C_BIGENDIAN(AC_SUBST([ENDIAN],[big]),AC_SUBST([ENDIAN],[little]))
dnl Check for C++ extensions
AC_CXX_HAVE_HASH_MAP
AC_CXX_HAVE_HASH_SET
AC_CXX_HAVE_EXT_SLIST
AC_CXX_HAVE_STD_ITERATOR
AC_CXX_HAVE_BI_ITERATOR
AC_CXX_HAVE_FWD_ITERATOR
dnl Checks for library functions.
dnl **************************************************************************
dnl * Checks for library functions.
dnl **************************************************************************
AC_FUNC_ALLOCA
AC_PROG_GCC_TRADITIONAL
AC_FUNC_MEMCMP
AC_FUNC_MMAP
if test "$ac_cv_func_mmap_fixed_mapped" = "no"
then
AC_MSG_ERROR([mmap() required but not found])
fi
AC_FUNC_MMAP_FILE
if test "$ac_cv_func_mmap_file" = "no"
if test ${ac_cv_func_mmap_file} = "no"
then
AC_MSG_ERROR([mmap() of files required but not found])
fi
AC_HEADER_MMAP_ANONYMOUS
AC_TYPE_SIGNAL
AC_CHECK_FUNCS(getcwd gettimeofday strdup strtoq strtoll backtrace)
AC_CHECK_FUNCS(getcwd gettimeofday strcspn strdup strerror strspn strstr strtod strtol strtoq strtoll)
dnl
dnl Need to check mmap for MAP_PRIVATE, MAP_ANONYMOUS, MAP_ANON, MAP_FIXED
dnl MAP_FIXED is only needed for Sparc
dnl MAP_ANON is used for Sparc and BSD
dnl Everyone should have MAP_PRIVATE
dnl
dnl Check for certain functions (even if we've already found them) so that we
dnl can quit with an error if they are unavailable.
dnl
dnl As the code is made more portable (i.e. less reliant on these functions,
dnl these checks should go away.
AC_CHECK_FUNC(mmap,,AC_MSG_ERROR([Function mmap() required but not found]))
AC_CHECK_FUNC(mprotect,,AC_MSG_ERROR([Function mprotect() required but not found]))
dnl Determine if the linker supports the -R option.
AC_LINK_USE_R
AC_LINK_USE_R()
dnl --enable/--with command-line options:
dnl Check whether they want to do an optimized build:
dnl **************************************************************************
dnl * Enable various compile-time options
dnl **************************************************************************
dnl Purify Option
AC_ARG_ENABLE(purify,AC_HELP_STRING([--enable-purify],[Compile with purify (default is NO)]),,enableval="no")
if test ${enableval} = "no"
then
AC_SUBST(ENABLE_PURIFY,[[]])
else
AC_SUBST(ENABLE_PURIFY,[[ENABLE_PURIFY=1]])
fi
dnl Optimized Option
AC_ARG_ENABLE(optimized,AC_HELP_STRING([--enable-optimized],[Compile with optimizations enabled (default is NO)]),,enableval=no)
if test ${enableval} = "no"
then
@@ -298,73 +412,28 @@ else
AC_SUBST(ENABLE_OPTIMIZED,[[ENABLE_OPTIMIZED=1]])
fi
dnl Spec 2000 Benchmarks
AC_ARG_ENABLE(spec2000,AC_HELP_STRING([--enable-spec2000],[Compile SPEC 2000 benchmarks (default is NO)]),,enableval=no)
dnl Spec Benchmarks
AC_ARG_ENABLE(spec2000,AC_HELP_STRING([--enable-spec],[Compile SPEC 2000 benchmarks (default is NO)]),,enableval=no)
if test ${enableval} = "no"
then
if test -d /home/vadve/shared/benchmarks/speccpu2000/benchspec
then
AC_SUBST(SPEC2000_ROOT,[/home/vadve/shared/benchmarks/speccpu2000/benchspec])
AC_SUBST(USE_SPEC2000,[[USE_SPEC2000=1]])
AC_SUBST(SPEC_ROOT,[/home/vadve/shared/benchmarks/speccpu2000/benchspec])
AC_SUBST(USE_SPEC,[[USE_SPEC=1]])
else
AC_SUBST(USE_SPEC2000,[[]])
AC_SUBST(SPEC2000_ROOT,[])
AC_SUBST(USE_SPEC,[[]])
AC_SUBST(SPEC_ROOT,[])
fi
else
if test ${enableval} = ""
then
AC_SUBST(SPEC2000_ROOT,[/home/vadve/shared/benchmarks/speccpu2000/benchspec])
AC_SUBST(SPEC_ROOT,[/home/vadve/shared/benchmarks/speccpu2000/benchspec])
else
AC_SUBST(SPEC2000_ROOT,[${enableval}])
AC_SUBST(SPEC_ROOT,[${enableval}])
fi
AC_SUBST(USE_SPEC2000,[[USE_SPEC2000=1]])
AC_SUBST(USE_SPEC,[[USE_SPEC=1]])
fi
dnl Spec 95 Benchmarks
AC_ARG_ENABLE(spec95,AC_HELP_STRING([--enable-spec95],[Compile SPEC 95 benchmarks (default is NO)]),,enableval=no)
if test ${enableval} = "no"
then
if test -d /home/vadve/shared/benchmarks/spec95/benchspec
then
AC_SUBST(SPEC95_ROOT,[/home/vadve/shared/benchmarks/spec95/benchspec])
AC_SUBST(USE_SPEC95,[[USE_SPEC95=1]])
else
AC_SUBST(USE_SPEC95,[[]])
AC_SUBST(SPEC95_ROOT,[])
fi
else
if test ${enableval} = ""
then
AC_SUBST(SPEC95_ROOT,[/home/vadve/shared/benchmarks/spec95/benchspec])
else
AC_SUBST(SPEC95_ROOT,[${enableval}])
fi
AC_SUBST(USE_SPEC95,[[USE_SPEC95=1]])
fi
dnl Povray External Benchmark
AC_ARG_ENABLE(povray,AC_HELP_STRING([--enable-povray],[Compile Povray benchmark (default is NO)]),,enableval=no)
if test ${enableval} = "no"
then
if test -d /home/vadve/shared/benchmarks/povray31
then
AC_SUBST(POVRAY_ROOT,[/home/vadve/shared/benchmarks/povray31])
AC_SUBST(USE_POVRAY,[[USE_POVRAY=1]])
else
AC_SUBST(USE_POVRAY,[[]])
AC_SUBST(POVRAY_ROOT,[])
fi
else
if test ${enableval} = ""
then
AC_SUBST(POVRAY_ROOT,[/home/vadve/shared/benchmarks/povray31])
else
AC_SUBST(POVRAY_ROOT,[${enableval}])
fi
AC_SUBST(USE_POVRAY,[[USE_POVRAY=1]])
fi
dnl Precompiled Bytecode Option
AC_ARG_ENABLE(precompiled_bytecode,AC_HELP_STRING([--enable-precompiled_bytecode],[Use pre-compiled bytecode (default is NO)]),,enableval=no)
if test ${enableval} = "no"
@@ -374,6 +443,7 @@ else
AC_SUBST(UPB,[[USE_PRECOMPILED_BYTECODE=1]])
fi
dnl LLC Diff Option
AC_ARG_ENABLE(llc_diffs,AC_HELP_STRING([--enable-llc_diffs],[Enable LLC Diffs when testing (default is YES)]),,enableval=yes)
if test ${enableval} = "no"
@@ -385,6 +455,7 @@ fi
dnl JIT Option
AC_ARG_ENABLE(jit,AC_HELP_STRING([--enable-jit],[Enable Just In Time Compiling (default is YES)]),,enableval=default)
if test ${enableval} = "no"
then
AC_SUBST(JIT,[[]])
@@ -402,8 +473,13 @@ else
esac
fi
dnl Find the LLVM GCC-based C/C++ front end
dnl **************************************************************************
dnl * Set the location of various third-party software packages
dnl **************************************************************************
dnl Location of the LLVM C front end
AC_ARG_WITH(llvmgccdir,AC_HELP_STRING([--with-llvmgccdir],[Location of LLVM GCC front-end]),AC_SUBST(LLVMGCCDIR,[$withval]))
AC_MSG_CHECKING([for llvm-gcc])
LLVM_GCC_CHECK=no
if test -d "$LLVMGCCDIR"
@@ -419,6 +495,7 @@ if test "$LLVM_GCC_CHECK" = "no"
then
llvmgccwarn=yes
fi
AC_MSG_CHECKING([whether llvm-gcc is sane])
LLVM_GCC_SANE=no
if test -x "$LLVM_GCC_CHECK"
@@ -430,10 +507,6 @@ then
LLVM_GCC_SANE=yes
fi
rm conftest.c
llvmcc1path=`"$LLVM_GCC_CHECK" --print-prog-name=cc1`
AC_SUBST(LLVMCC1,$llvmcc1path)
llvmcc1pluspath=`"$LLVM_GCC_CHECK" --print-prog-name=cc1plus`
AC_SUBST(LLVMCC1PLUS,$llvmcc1pluspath)
fi
AC_MSG_RESULT($LLVM_GCC_SANE)
if test "$LLVM_GCC_SANE" = "no"
@@ -447,25 +520,18 @@ AC_ARG_WITH(bcrepos,AC_HELP_STRING([--with-bcrepos],[Location of Bytecode Reposi
dnl Location of PAPI
AC_ARG_WITH(papi,AC_HELP_STRING([--with-papi],[Location of PAPI]),AC_SUBST(PAPIDIR,[$withval]),AC_SUBST(PAPIDIR,[/home/vadve/shared/Sparc/papi-2.3.4.1]))
dnl Get libtool's idea of what the shared library suffix is.
dnl (This is a hack; it relies on undocumented behavior.)
AC_MSG_CHECKING([for shared library suffix])
eval "SHLIBEXT=$shrext"
AC_MSG_RESULT($SHLIBEXT)
dnl Propagate it to the Makefiles and config.h (for gccld & bugpoint).
AC_SUBST(SHLIBEXT,$SHLIBEXT)
AC_DEFINE_UNQUOTED(SHLIBEXT,"$SHLIBEXT",
[Extension that shared libraries have, e.g., ".so".])
dnl Location of the purify program
AC_ARG_WITH(purify,AC_HELP_STRING([--with-purify],[Location of purify program]),AC_SUBST(PURIFY,[$withval]))
dnl Create the output files
AC_OUTPUT(Makefile.config
include/Support/DataTypes.h
include/Support/ThreadSupport.h
include/Support/hash_map
include/Support/hash_set
include/Support/iterator)
dnl **************************************************************************
dnl * Configure other software packages (via AC_CONFIG_SUBDIRS)
dnl **************************************************************************
dnl **************************************************************************
dnl * Create the output files
dnl **************************************************************************
AC_OUTPUT(Makefile.config)
dnl Warn loudly if llvm-gcc was not obviously working
if test $llvmgccwarn = yes
then
AC_MSG_WARN([***** llvm C/C++ front end was not found, or does not])
@@ -475,4 +541,3 @@ then
AC_MSG_WARN([***** Runtime libraries (in llvm/runtime) will not be built,])
AC_MSG_WARN([***** but you should be able to build the llvm tools.])
fi

1859
llvm/configure vendored

File diff suppressed because it is too large Load Diff

View File

@@ -2,8 +2,8 @@
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>Alias Analysis Infrastructure in LLVM</title>
<link rel="stylesheet" href="llvm.css" type="text/css">
<title>Alias Analysis Infrastructure in LLVM</title>
</head>
<body>
@@ -65,7 +65,7 @@ href="#MustNoMay">Must, May, or No</a> alias response, indicating that two
pointers do point to the same object, might point to the same object, or are
known not to point to the same object.</p>
<p>The <a href="/doxygen/classllvm_1_1AliasAnalysis.html">AliasAnalysis</a> class is the
<p>The <a href="/doxygen/classAliasAnalysis.html">AliasAnalysis</a> class is the
centerpiece of the LLVM Alias Analysis related infrastructure. This class is
the common interface between clients of alias analysis information and the
implementations providing it. In addition to simple alias analysis information,
@@ -89,7 +89,7 @@ know</a>.</p>
<div class="doc_text">
<p>The <a href="/doxygen/classllvm_1_1AliasAnalysis.html">AliasAnalysis</a> class
<p>The <a href="/doxygen/classAliasAnalysis.html">AliasAnalysis</a> class
defines the interface that Alias Analysis implementations should support. This
class exports two important enums: <tt>AliasResult</tt> and
<tt>ModRefResult</tt> which represent the result of an alias query or a mod/ref
@@ -199,7 +199,7 @@ is returned.</p>
straight-forward. There are already several implementations that you can use
for examples, and the following information should help fill in any details.
For a minimal example, take a look at the <a
href="/doxygen/structllvm_1_1NoAA.html"><tt>no-aa</tt></a> implementation.</p>
href="/doxygen/structNoAA.html"><tt>no-aa</tt></a> implementation.</p>
</div>
@@ -277,7 +277,7 @@ a <tt>BasicBlockPass</tt>, or <tt>InitializeAliasAnalysis</tt> for an
<div class="doc_text">
<p>All of the <a href="/doxygen/classllvm_1_1AliasAnalysis.html">AliasAnalysis</a>
<p>All of the <a href="/doxygen/classAliasAnalysis.html">AliasAnalysis</a>
virtual methods default to providing conservatively correct information
(returning "May" Alias and "Mod/Ref" for alias and mod/ref queries
respectively). Depending on the capabilities of the analysis you are
@@ -355,7 +355,7 @@ to do anything special to handle load instructions: just use the
<p>Many transformations need information about alias <b>sets</b> that are active
in some scope, rather than information about pairwise aliasing. The <tt><a
href="/doxygen/classllvm_1_1AliasSetTracker.html">AliasSetTracker</a></tt> class is used
href="/doxygen/classAliasSetTracker.html">AliasSetTracker</a></tt> class is used
to efficiently build these Alias Sets from the pairwise alias analysis
information provided by the AliasAnalysis interface.</p>
@@ -366,9 +366,9 @@ simply iterate through the constructed alias sets, using the AliasSetTracker
<tt>begin()</tt>/<tt>end()</tt> methods.</p>
<p>The <tt>AliasSet</tt>s formed by the <tt>AliasSetTracker</tt> are guaranteed
to be disjoint, calculate mod/ref information and volatility for the set, and
keep track of whether or not all of the pointers in the set are Must aliases.
The AliasSetTracker also makes sure that sets are properly folded due to call
to be disjoint, calculate mod/ref information for the set, and keep track of
whether or not all of the pointers in the set are Must aliases. The
AliasSetTracker also makes sure that sets are properly folded due to call
instructions, and can provide a list of pointers in each set.</p>
<p>As an example user of this, the <a href="/doxygen/structLICM.html">Loop
@@ -376,38 +376,11 @@ Invariant Code Motion</a> pass uses AliasSetTrackers to build alias information
about each loop nest. If an AliasSet in a loop is not modified, then all load
instructions from that set may be hoisted out of the loop. If any alias sets
are stored <b>and</b> are must alias sets, then the stores may be sunk to
outside of the loop, promoting the memory location to a register for the
duration of the loop nest. Both of these transformations obviously only apply
if the pointer argument is loop-invariant.</p>
outside of the loop. Both of these transformations obviously only apply if the
pointer argument is loop-invariant.</p>
</div>
<div class="doc_subsubsection">
The AliasSetTracker implementation
</div>
<div class="doc_text">
<p>The AliasSetTracker class is implemented to be as efficient as possible. It
uses the union-find algorithm to efficiently merge AliasSets when a pointer is
inserted into the AliasSetTracker that aliases multiple sets. The primary data
structure is a hash table mapping pointers to the AliasSet they are in.</p>
<p>The AliasSetTracker class must maintain a list of all of the LLVM Value*'s
that are in each AliasSet. Since the hash table already has entries for each
LLVM Value* of interest, the AliasesSets thread the linked list through these
hash-table nodes to avoid having to allocate memory unnecessarily, and to make
merging alias sets extremely efficient (the linked list merge is constant time).
</p>
<p>You shouldn't need to understand these details if you are just a client of
the AliasSetTracker, but if you look at the code, hopefully this brief
description will help make sense of why things are designed the way they
are.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="direct">Using the AliasAnalysis interface directly</a>
@@ -506,7 +479,7 @@ printed.</p>
<hr>
<address>
<a href="http://jigsaw.w3.org/css-validator/check/referer"><img
<a href="http://jigsaw.w3.org/css-validator/"><img
src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
<a href="http://validator.w3.org/check/referer"><img
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>

View File

@@ -89,8 +89,6 @@ process, and you should <b>only</b> try to do it if:</p>
<p>
<b>Linux/x86:</b>
<br>
<b>MacOS X/PowerPC:</b>
</p>
<pre>
@@ -103,25 +101,37 @@ process, and you should <b>only</b> try to do it if:</p>
</pre>
<p>
<b>Solaris/SPARC:</b>
<b>Solaris/Sparc:</b>
</p>
<p>
For Solaris/SPARC, LLVM only supports the SPARC V9. Therefore, the
configure command line should specify sparcv9, as shown below. Also,
note that Solaris has trouble with various wide (multibyte) character
functions from C as referenced from C++, so we typically configure with
--disable-c-mbchar (cf. <a href="http://llvm.cs.uiuc.edu/PR206">Bug 206</a>).
For Solaris/Sparc, LLVM only supports SparcV9. Therefore, the configure
command line should like something like this:
</p>
<pre>
% cd build
% ../src/configure --prefix=$CFEINSTALL --disable-threads --disable-nls \
--disable-shared --enable-languages=c,c++ --host=sparcv9-sun-solaris2.8 \
--disable-c-mbchar
% ../src/configure --prefix=$CFEINSTALL --disable-threads --disable-nls --disable-shared \
--enable-languages=c,c++ --host=sparcv9-sun-solaris2.8
% gmake all-gcc
% setenv LLVM_LIB_SEARCH_PATH `pwd`/gcc
% gmake all; gmake install
% gmake all
</pre>
<p>
At this point, libstdc++ may fail to build because of wchar errors (look for
errors that reference <tt>vfwscanf</tt> or <tt>wcstof</tt>). If that happens,
edit <tt>sparcv9-sun-solaris2.8/libstdc++-v3/config.h</tt> and comment out the
line that defines <tt>_GLIBCXX_USE_WCHAR_T</tt>.
</p>
<p>
Then, continue as below:
</p>
<pre>
% gmake all
% gmake install
</pre>
<p><b>Common Problem:</b> You may get error messages regarding the fact
@@ -187,7 +197,7 @@ libgcc.a library, which you can find by running
<pre>
% gmake -C runtime
% mkdir $CFEINSTALL/bytecode-libs
% gmake -C runtime install-bytecode
% gmake -C runtime install
% setenv LLVM_LIB_SEARCH_PATH $CFEINSTALL/bytecode-libs
</pre></li>
@@ -220,26 +230,6 @@ The software also has the following additional copyrights:
</p>
<pre>
Copyright (c) 2003, 2004 University of Illinois at Urbana-Champaign.
All rights reserved.
Developed by:
LLVM Team
University of Illinois at Urbana-Champaign
http://llvm.cs.uiuc.edu
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
CONTRIBUTORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS WITH THE
SOFTWARE.
Copyright (c) 1994
Hewlett-Packard Company

View File

@@ -35,29 +35,6 @@ language.
Print a summary of command line options.
<p>
<li> -q
<br>
Quiet mode. With this option, analysis pass names are not printed.
<p>
<li> -load &lt;plugin&gt;
<br>
Load the specified dynamic object with name <tt>plugin</tt>. This file
should contain additional analysis passes that register themselves with
the <tt>analyze</tt> program after being loaded.
<p>
After being loaded, additional command line options are made available
for running the passes made available by <tt>plugin</tt>. Use
'<tt><tt>analyze</tt> -load &lt;plugin&gt; -help</tt>' to see the new
list of available analysis passes.
<p>
<li> -profile-info-file &lt;filename&gt;
<br>
Specify the name of the file loaded by the -profile-loader option.
<p>
<li> -stats
<br>
Print statistics.
@@ -68,6 +45,24 @@ language.
Record the amount of time needed for each pass and print it to standard
error.
<p>
<li> -q
<br>
Quiet mode. With this option, analysis pass names are not printed.
<p>
<li> -load &lt;plugin.so&gt;
<br>
Load the specified dynamic object with name plugin.so. This file
should contain additional analysis passes that register themselves with
the <tt>analyze</tt> program after being loaded.
<p>
After being loaded, additional command line options are made available
for running the passes made available by plugin.so. Use
'<tt><tt>analyze</tt> -load &lt;plugin.so&gt; -help</tt>' to see the new
list of available analysis passes.
<p>
</ul>
<h3>EXIT STATUS</h3>

View File

@@ -47,43 +47,43 @@ any of the passes crash, or if they produce malformed output,
<tt>bugpoint</tt> starts the <a href="#crashdebug">crash debugger</a>.<p>
Otherwise, if the <a href="#opt_output"><tt>-output</tt></a> option was not
specified, <tt>bugpoint</tt> runs the test program with the C backend (which is
assumed to generate good code) to generate a reference output. Once
specified, <tt>bugpoint</tt> runs the test program with the C backend (which
is assumed to generate good code) to generate a reference output. Once
<tt>bugpoint</tt> has a reference output for the test program, it tries
executing it with the <a href="#opt_run-">selected</a> code generator. If the
selected code generator crashes, <tt>bugpoint</tt> starts the <a
href="#crashdebug">crash debugger</a> on the code generator. Otherwise, if the
resulting output differs from the reference output, it assumes the difference
resulted from a code generator failure, and starts the <a
href="#codegendebug">code generator debugger</a>.<p>
executing it
with the <a href="#opt_run-">selected</a> code generator. If
the resulting output differs from the reference output, it assumes the
difference resulted from a code generator failure, and starts the
<a href="#codegendebug">code generator debugger</a>.<p>
Finally, if the output of the selected code generator matches the reference
output, <tt>bugpoint</tt> runs the test program after all of the LLVM passes
have been applied to it. If its output differs from the reference output, it
assumes the difference resulted from a failure in one of the LLVM passes, and
enters the <a href="#miscompilationdebug">miscompilation
debugger</a>. Otherwise, there is no problem <tt>bugpoint</tt> can debug.<p>
Otherwise, <tt>bugpoint</tt> runs the test program after all of the LLVM passes
have been applied to it. If its output differs from the reference output,
it assumes the difference resulted from a failure in one of the LLVM passes,
and enters the
<a href="#miscompilationdebug">miscompilation debugger</a>. Otherwise,
there is no problem <tt>bugpoint</tt> can debug.<p>
<a name="crashdebug">
<h4>Crash debugger</h4>
If an optimizer or code generator crashes, <tt>bugpoint</tt> will try as hard as
it can to reduce the list of passes (for optimizer crashes) and the size of the
test program. First, <tt>bugpoint</tt> figures out which combination of
optimizer passes triggers the bug. This is useful when debugging a problem
exposed by <tt>gccas</tt>, for example, because it runs over 25
optimizations.<p>
If an optimizer crashes, <tt>bugpoint</tt> will try as hard as it can to
reduce the list of passes and the size of the test program. First,
<tt>bugpoint</tt> figures out which combination of passes triggers the bug. This
is useful when debugging a problem exposed by <tt>gccas</tt>, for example,
because it runs over 25 optimizations.<p>
Next, <tt>bugpoint</tt> tries removing functions from the test program, to
reduce its size. Usually it is able to reduce a test program to a single
function, when debugging intraprocedural optimizations. Once the number of
reduce its
size. Usually it is able to reduce a test program
to a single function, when debugging intraprocedural optimizations. Once the
number of
functions has been reduced, it attempts to delete various edges in the control
flow graph, to reduce the size of the function as much as possible. Finally,
<tt>bugpoint</tt> deletes any individual LLVM instructions whose absence does
not eliminate the failure. At the end, <tt>bugpoint</tt> should tell you what
passes crash, give you a bytecode file, and give you instructions on how to
reproduce the failure with <tt><a href="opt.html">opt</a></tt>, <tt><a
href="analyze.html">analyze</a></tt>, or <tt><a href="llc.html">llc</a></tt>.<p>
reproduce the failure with <tt><a href="opt.html">opt</a></tt> or
<tt><a href="analyze.html">analyze</a></tt>.<p>
<a name="codegendebug">
<h4>Code generator debugger</h4>
@@ -152,19 +152,14 @@ non-obvious ways. Here are some hints and tips:<p>
<tt>bugpoint</tt> crashes before you see its "All input ok" message,
you might try <tt>llvm-link -v</tt> on the same set of input files. If
that also crashes, you may be experiencing a linker bug.
<li>If your program is <b>supposed</b> to crash, <tt>bugpoint</tt> will be
confused. One way to deal with this is to cause bugpoint to ignore the exit
code from your program, by giving it the <tt>-check-exit-code=false</tt>
option.
</ol>
<h3>OPTIONS</h3>
<ul>
<li><tt>-additional-so &lt;library&gt;</tt><br>
Load <tt>&lt;library&gt;</tt> into the test program whenever it is run.
<li><tt>-additional-so &lt;library.so&gt;</tt><br>
Load <tt>&lt;library.so&gt;</tt> into the test program whenever it is run.
This is useful if you are debugging programs which depend on non-LLVM
libraries (such as the X or curses libraries) to run.<p>
@@ -180,26 +175,12 @@ non-obvious ways. Here are some hints and tips:<p>
part of the <tt>-args</tt> option, not as options to <tt>bugpoint</tt>
itself.<p>
<li><tt>-check-exit-code={true,false}</tt><br>
Assume a non-zero exit code or core dump from the test program is
a failure. Defaults to true.<p>
<li><tt>-disable-{dce,simplifycfg}</tt><br>
<li><tt>-disable-{adce,dce,simplifycfg}</tt><br>
Do not run the specified passes to clean up and reduce the size of the
test program. By default, <tt>bugpoint</tt> uses these passes internally
when attempting to reduce test programs. If you're trying to find
a bug in one of these passes, <tt>bugpoint</tt> may crash.<p>
<li><tt>-enable-correct-eh-support</tt><br>
Make the -lowerinvoke pass insert expensive, but correct, exception
handling code.<p>
<li><tt>-internalize-public-api-file &lt;filename&gt;</tt><br>
Preserve the symbols listed in the file <tt>filename</tt>.<p>
<li><tt>-internalize-public-api-list &lt;list&gt;</tt><br>
Preserve the symbols listed in <tt>list</tt>.<p>
<li> <tt>-help</tt><br>
Print a summary of command line options.<p>
@@ -208,14 +189,14 @@ non-obvious ways. Here are some hints and tips:<p>
test program, whenever it runs, to come from that file.
<p>
<a name="opt_load"><li> <tt>-load &lt;plugin&gt;</tt><br>
Load the dynamic object <tt>&lt;plugin&gt;</tt> into <tt>bugpoint</tt>
<a name="opt_load"><li> <tt>-load &lt;plugin.so&gt;</tt><br>
Load the dynamic object <tt>&lt;plugin.so&gt;</tt> into <tt>bugpoint</tt>
itself. This object should register new
optimization passes. Once loaded, the object will add new command line
options to enable various optimizations. To see the new complete list
of optimizations, use the -help and -load options together:
<p>
<tt>bugpoint -load &lt;plugin&gt; -help</tt>
<tt>bugpoint -load &lt;plugin.so&gt; -help</tt>
<p>
<a name="opt_output"><li><tt>-output &lt;filename&gt;</tt><br>
@@ -225,9 +206,6 @@ non-obvious ways. Here are some hints and tips:<p>
<tt>bugpoint</tt> will attempt to generate a reference output by
compiling the program with the C backend and running it.<p>
<li><tt>-profile-info-file &lt;filename&gt;</tt><br>
Profile file loaded by -profile-loader.<p>
<a name="opt_run-"><li><tt>-run-{int,jit,llc,cbe}</tt><br>
Whenever the test program is compiled, <tt>bugpoint</tt> should generate
code for it using the specified code generator. These options allow

View File

@@ -35,17 +35,11 @@ unused types.
The <tt>extract</tt> command reads its input from standard input if filename is
omitted or if filename is -. The output is always written to standard output.
<h3>OPTIONS</h3>
<h3>
OPTIONS
</h3>
<ul>
<ul>
<li> -f
<br>
Force overwrite. Normally, <tt>extract</tt> will refuse to overwrite an
output file that already exists. With this option, <tt>extract</tt>
will overwrite the output file and replace it with new bytecode.
<p>
<li>-func &lt;function&gt;
<br>
Extract the specified function from the LLVM bytecode.
@@ -55,23 +49,6 @@ omitted or if filename is -. The output is always written to standard output.
<br>
Print a summary of command line options.
<p>
<li> -o &lt;filename&gt;
<br>
Specify the output filename. If filename is "-" (the default), then
<tt>extract</tt> sends its output to standard output.
<p>
<li> -stats
<br>
Print statistics.
<p>
<li> -time-passes
<br>
Record the amount of time needed for each pass and print it to standard
error.
<p>
</ul>
<h3>

View File

@@ -44,17 +44,6 @@ OPTIONS
Disable the inlining pass. By default, it is enabled.
<p>
<li> -disable-opt
<br>
Disable all assemble-time optimization passes.
<p>
<li>-enable-correct-eh-support
<br>
Instruct the -lowerinvoke pass to insert code for correct exception handling
support. This is expensive and is by default omitted for efficiency.
<p>
<li> -stats
<br>
Print statistics.

View File

@@ -32,35 +32,24 @@ optimizations on the program.
<h4>Search Order</h4>
<p>
When looking for objects specified on the command line, <tt>gccld</tt> will
search for the object first in the current directory and then in the directory
specified by the <tt>LLVM_LIB_SEARCH_PATH</tt> environment variable. If it
cannot find the object, it fails.
</p>
<p>
When looking for a library specified with the -l option, <tt>gccld</tt> first
attempts to load a file with that name from the current directory. If that
fails, it looks for lib&lt;library&gt;.bc, lib&lt;library&gt;.a, or
lib&lt;library&gt;.&lt;shared library extension&gt;, in that order, in each
directory added to the library search path with the -L option. These
directories are searched in the order they
lib&lt;library&gt;.so, in that order, in each directory added to the library
search path with the -L option. These directories are searched in order they
were specified. If the library cannot be located, then <tt>gccld</tt> looks in
the directory specified by the <tt>LLVM_LIB_SEARCH_PATH</tt> environment
variable. If it does not find a library there, it fails.
</p>
variable. If it does not find lib&lt;library&gt;.[bc | a | so] there, it fails.
<p>
The shared library extension is usually <tt>.so</tt>, but it may differ
depending upon the system.
</p>
<p>
The -L option is global. It does not matter where it is specified in the list
of command line arguments; the directory is simply added to the search path and
is applied to all libraries, preceding or succeeding, in the command line.
</p>
<h4>Link order</h4>
@@ -114,12 +103,7 @@ using the -native option.
<li> -disable-opt
<br>
Disable all link-time optimization passes.
<p>
<li> -disable-inlining
<br>
Do not run the inliner pass.
Disable all link-time optimization passes.
<p>
<li> -L=&lt;directory&gt;
@@ -147,9 +131,9 @@ using the -native option.
<br>
Specify libraries to include when linking the output file. When
linking, <tt>gccld</tt> will first attempt to load a file with the
pathname <tt>library</tt>. If that fails, it will then attempt to load
lib&lt;library&gt;.bc, lib&lt;library&gt;.a, and
lib&lt;library&gt;.&lt;shared library extension&gt;, in that order.
pathname library. If that fails, it will then attempt to load
lib&lt;library&gt;.bc, lib&lt;library&gt;.a, and lib&lt;library&gt;.so,
in that order.
<p>
<li> -link-as-library

View File

@@ -90,14 +90,11 @@ OPTIONS
architectures are:
<dl compact>
<dt> x86 </dt>
<di> x86
<dd>IA-32 (Pentium and above)</dd>
<dt> sparcv9 </dt>
<di> sparc
<dd>SPARC V9</dd>
<dt> c </dt>
<dd>Emit C code</dd>
</dl>
<p>
@@ -106,12 +103,6 @@ OPTIONS
Specify the output filename.
<p>
<li>-enable-correct-eh-support
<br>
Instruct the -lowerinvoke pass to insert code for correct exception handling
support. This is expensive and is by default omitted for efficiency.
<p>
<li> -help
<br>
Print a summary of command line options.
@@ -148,34 +139,16 @@ OPTIONS
<li>-regalloc=&lt;ra&gt;
<br>
Specify the register allocator to use. The default is <i>local</i>.
Specify the register allocator to use. The default is <i>simple</i>.
Valid register allocators are:
<p>
<dl compact>
<dt> simple </dt>
<di> simple
<dd>Very simple register allocator</dd>
<dt> local </dt>
<di> local
<dd>Local register allocator</dd>
<dt> linearscan </dt>
<dd>Linear scan global register allocator (experimental)</dd>
</dl>
<li>-spiller=&lt;sp&gt;
<br>
Specify the spiller to use for register allocators that support it.
Currently this option is used by the linear scan register
allocator. The default is <i>local</i>.
Valid spillers are:
<p>
<dl compact>
<dt> simple </dt>
<dd>Simple spiller</dd>
<dt> local </dt>
<dd>Local spiller</dd>
</dl>
<p>
</ul>
@@ -186,6 +159,11 @@ OPTIONS
Disable peephole optimization pass.
<p>
<li>-disable-preopt
<br>
Disable optimizations prior to instruction selection.
<p>
<li>-disable-sched
<br>
Disable local scheduling pass.

View File

@@ -53,6 +53,11 @@ The default output file for <tt>llvm-dis</tt> is determined by the following log
readable format. This is the default behavior.
<p>
<li> -c
<br>
Instruct <tt>llvm-dis</tt> to generate C source code.
<p>
<li> -f
<br>
Force overwrite. Normally, <tt>llvm-dis</tt> will refuse to overwrite

View File

@@ -10,19 +10,18 @@
<tt>llvm-prof</tt>
<h3>SYNOPSIS</h3>
<tt>llvm-prof [options] [bytecode file] [llvmprof.out]</tt>
<tt>llvm-prof [options] [bytecode file] [LLVM passes]</tt>
<h3>DESCRIPTION</h3>
The <tt>llvm-prof</tt> tool reads in an '<tt>llvmprof.out</tt>' file (which can
optionally use a specific file with the third program argument), a bytecode file
for the program, and produces a human readable report, suitable for determining
where the program hotspots are.<p>
The <tt>llvm-prof</tt> tool reads in an '<tt>llvmprof.out</tt>' file, a bytecode
file for the program, and produces a human readable report, suitable for
determining where the program hotspots are.<p>
This program is often used in conjunction with the <tt>utils/profile.pl</tt>
This program is often used in conjunction with the <tt>utils/profile.sh</tt>
script. This script automatically instruments a program, runs it with the JIT,
then runs <tt>llvm-prof</tt> to format a report. To get more information about
<tt>utils/profile.pl</tt>, execute it with the <tt>--help</tt> option.<p>
<tt>utils/profile.sh</tt>, execute it with the <tt>--help</tt> option.<p>
<h3>OPTIONS</h3>
@@ -30,7 +29,7 @@ then runs <tt>llvm-prof</tt> to format a report. To get more information about
<li><tt>--annotated-llvm</tt> or <tt>-A</tt><br>
In addition to the normal report printed, print out the code for the
program, annotated with execution frequency information. This can be
program, annotated we execution frequency information. This can be
particularly useful when trying to visualize how frequently basic blocks
are executed. This is most useful with basic block profiling
information or better.<p>
@@ -40,17 +39,12 @@ then runs <tt>llvm-prof</tt> to format a report. To get more information about
Using this option enables the <tt>--annotated-llvm</tt> option, but it
prints the entire module, instead of just the most commonly executed
functions.<p>
<li><tt>-time-passes</tt><br>
Record the amount of time needed for each pass and print it to standard
error.
</ul>
<h3>EXIT STATUS</h3>
<tt>llvm-prof</tt> returns 1 if it cannot load the bytecode file or the profile
information. Otherwise, it exits with zero.
information, otherwise it exits with zero.
<HR>
Maintained by the <a href="http://llvm.cs.uiuc.edu">LLVM Team</a>.

View File

@@ -53,11 +53,6 @@ writes its output to the standard output.
Specify the output filename.
<p>
<li> -profile-info-file &lt;filename&gt;
<br>
Specify the name of the file loaded by the -profile-loader option.
<p>
<li> -stats
<br>
Print statistics.
@@ -93,14 +88,14 @@ writes its output to the standard output.
Quiet mode. Do not print messages on whether the program was modified.
<p>
<li> -load &lt;plugin&gt;
<li> -load &lt;plugin.so&gt;
<br>
Load the dynamic object &lt;plugin&gt;. This object should register new
Load the dynamic object &lt;plugin.so&gt;. This object should register new
optimization passes. Once loaded, the object will add new command line
options to enable various optimizations. To see the new complete list
of optimizations, use the -help and -load options together:
<p>
<tt>opt -load &lt;plugin&gt; -help</tt>
<tt>opt -load &lt;plugin.so&gt; -help</tt>
<p>
<li> -p

View File

@@ -48,9 +48,7 @@
errors.</li>
<li>I've built LLVM and am testing it, but the tests freeze.</li>
<li>Why do test results differ when I perform different types of builds?</li>
<li>Compiling LLVM with GCC 3.3.2 fails, what should I do?</li>
<li>When I use the test suite, all of the C Backend tests fail. What is
wrong?</li>
<li>Compiling LLVM with GCC 3.3 on SuSE 9 fails, what should I do?</li>
</ol></li>
<li><a href="#cfe">Using the GCC Front End</a>
@@ -72,7 +70,6 @@
<ol>
<li>What is this <tt>__main()</tt> call that gets inserted into
<tt>main()</tt>?</li>
<li>Where did all of my code go??</li>
</ol>
</li>
</ol>
@@ -113,7 +110,7 @@ Source Initiative (OSI).</p>
<div class="answer">
<p>Yes. The modified source distribution must retain the copyright notice and
follow the three bulletted conditions listed in the <a
href="http://llvm.cs.uiuc.edu/releases/1.2/LICENSE.TXT">LLVM license</a>.</p>
href="http://llvm.cs.uiuc.edu/releases/1.0/LICENSE.TXT">LLVM license</a>.</p>
</div>
<div class="question">
@@ -332,37 +329,12 @@ build.</p>
</div>
<div class="question">
<p>Compiling LLVM with GCC 3.3.2 fails, what should I do?</p>
<p>Compiling LLVM with GCC 3.3 on SuSE 9 fails, what should I do?</p>
</div>
<div class="answer">
<p>This is <a href="http://gcc.gnu.org/PR?13392">a bug in GCC</a>, and
affects projects other than LLVM. Try upgrading or downgrading your GCC.</p>
</div>
<div class="question">
<p>
When I use the test suite, all of the C Backend tests fail. What is
wrong?
</p>
</div>
<div class="answer">
<p>
If you build LLVM and the C Backend tests fail in <tt>llvm/test/Programs</tt>,
then chances are good that the directory pointed to by the LLVM_LIB_SEARCH_PATH
environment variable does not contain the libcrtend.a library.
</p>
<p>
To fix it, verify that LLVM_LIB_SEARCH_PATH points to the correct directory
and that libcrtend.a is inside. For pre-built LLVM GCC front ends, this
should be the absolute path to
<tt>cfrontend/&lt;<i>platform</i>&gt;/llvm-gcc/bytecode-libs</tt>. If you've
built your own LLVM GCC front end, then ensure that you've built and installed
the libraries in <tt>llvm/runtime</tt> and have LLVM_LIB_SEARCH_PATH pointing
to the <tt>LLVMGCCDIR/bytecode-libs</tt> subdirectory.
</p>
<p>This is a bug in the customized version of GCC shipped with SuSE, and affects
projects other than LLVM. Complain loudly to SuSE. :)</p>
</div>
<!-- *********************************************************************** -->
@@ -415,13 +387,13 @@ not linking on your system because the feature isn't available on your system.
<div class="question">
<p>
When I compile code using the LLVM GCC front end, it complains that it cannot
find libcrtend.a.
find crtend.o.
</p>
</div>
<div class="answer">
<p>
In order to find libcrtend.a, you must have the directory in which it lives in
In order to find crtend.o, you must have the directory in which it lives in
your LLVM_LIB_SEARCH_PATH environment variable. For the binary distribution of
the LLVM GCC front end, this will be the full path of the bytecode-libs
directory inside of the LLVM GCC distribution.
@@ -434,9 +406,11 @@ directory inside of the LLVM GCC distribution.
<a name="cfe_code">Questions about code generated by the GCC front-end</a>
</div>
<div class="question"><p>
<div class="question">
<p>
What is this <tt>__main()</tt> call that gets inserted into <tt>main()</tt>?
</p></div>
</p>
</div>
<div class="answer">
<p>
@@ -452,29 +426,10 @@ The actual implementation of <tt>__main</tt> lives in the
<tt>llvm/runtime/GCCLibraries/crtend/</tt> directory in the source-base, and is
linked in automatically when you link the program.
</p>
</div>
<!--=========================================================================-->
<div class="question"><p>
Where did all of my code go??
</p></div>
<div class="answer">
<p>
If you are using the LLVM demo page, you may often wonder what happened to all
of the code that you typed in. Remember that the demo script is running the
code through the LLVM optimizers, so if your code doesn't actually do anything
useful, it might all be deleted.
</p>
<p>
To prevent this, make sure that the code is actually needed. For example, if
you are computing some expression, return the value from the function instead of
leaving it in a local variable. If you really want to constrain the optimizer,
you can read from and assign to <tt>volatile</tt> global variables.
</p>
</div>
<!-- *********************************************************************** -->
<!-- *********************************************************************** -->

View File

@@ -96,8 +96,8 @@ from the LLVM suite.</p>
<ol>
<li><tt>cd <i>where-you-want-the-C-front-end-to-live</i></tt>
<li><tt>gunzip --stdout cfrontend.<i>platform</i>.tar.gz | tar -xvf -</tt>
<li><b>Sparc and MacOS X Only:</b><br>
<tt>cd cfrontend/<i>platform</i><br>
<li><b>Sparc Only:</b><br>
<tt>cd cfrontend/sparc<br>
./fixheaders</tt>
</ol></li>
@@ -106,7 +106,7 @@ from the LLVM suite.</p>
<li>With the distributed files:
<ol>
<li><tt>cd <i>where-you-want-llvm-to-live</i></tt>
<li><tt>gunzip --stdout llvm-<i>version</i>.tar.gz | tar -xvf -</tt>
<li><tt>gunzip --stdout llvm.tar.gz | tar -xvf -</tt>
<li><tt>cd llvm</tt>
</ol></li>
@@ -182,43 +182,49 @@ software you will need.</p>
<li>Linux on x86 (Pentium and above)
<ul>
<li>Approximately 1.02 GB of Free Disk Space
<li>Approximately 918 MB of Free Disk Space
<ul>
<li>Source code: 45 MB</li>
<li>Object code: 956 MB</li>
<li>GCC front end: 40 MB</li>
</ul></li>
</ul>
</li>
<li>Solaris on SparcV9 (Ultrasparc)
<ul>
<li>Approximately 1.75 GB of Free Disk Space
<ul>
<li>Source code: 45 MB</li>
<li>Object code: 1705 MB</li>
<li>GCC front end: 50 MB</li>
</ul></li>
</ul>
</li>
<li>FreeBSD on x86 (Pentium and above)
<ul>
<li>Approximately 935 MB of Free Disk Space
<ul>
<li>Source code: 45 MB</li>
<li>Source code: 28 MB</li>
<li>Object code: 850 MB</li>
<li>GCC front end: 40 MB</li>
</ul></li>
</ul>
</li>
<p></p>
<li>Solaris on SparcV9 (Ultrasparc)
<ul>
<li>Approximately 1.52 GB of Free Disk Space
<ul>
<li>Source code: 28 MB</li>
<li>Object code: 1470 MB</li>
<li>GCC front end: 50 MB</li>
</ul></li>
</ul>
</li>
<p></p>
<li>FreeBSD on x86 (Pentium and above)
<ul>
<li>Approximately 918 MB of Free Disk Space
<ul>
<li>Source code: 28 MB</li>
<li>Object code: 850 MB</li>
<li>GCC front end: 40 MB</li>
</ul></li>
</ul>
</li>
<p></p>
<li>MacOS X on PowerPC
<ul>
<li>No native code generation
<li>Approximately 1.25 GB of Free Disk Space
<li>Approximately 1.20 GB of Free Disk Space
<ul>
<li>Source code: 45 MB</li>
<li>Source code: 28 MB</li>
<li>Object code: 1160 MB</li>
<li>GCC front end: 40 MB</li>
</ul></li>
@@ -264,33 +270,17 @@ installed:</p>
LLVM:</p>
<ul>
<li><A href="http://www.gnu.org/software/automake">GNU Automake</A></li>
<li><A href="http://www.gnu.org/software/autoconf">GNU Autoconf</A></li>
<li><A href="http://www.gnu.org/software/autoconf">GNU Autoconf</A>
<li><A href="http://savannah.gnu.org/projects/m4">GNU M4</A>
<p>If you want to make changes to the configure scripts, you will need GNU
autoconf (2.57 or higher), and consequently, GNU M4 (version 1.4 or
higher). You will also need automake. Any old version of
automake from 1.4p5 on should work; we only use aclocal from that
package.</p></li>
higher).</p></li>
<li><A href="http://www.codesourcery.com/qm/qmtest">QMTest 2.0.3</A></li>
<li><A href="http://www.codesourcery.com/qm/qmtest">QMTest</A></li>
<li><A href="http://www.python.org">Python</A>
<p>
These are needed to use the LLVM test suite. Please note that newer
versions of QMTest may not work with the LLVM test suite. QMTest 2.0.3
can be retrieved from the QMTest CVS repository using the following
commands:
<ul>
<li><tt>cvs -d :pserver:anoncvs@cvs.codesourcery.com:/home/qm/Repository login</tt>
</li>
<li>When prompted, use <tt>anoncvs</tt> as the password.
</li>
<li><tt>cvs -d :pserver:anoncvs@cvs.codesourcery.com:/home/qm/Repository co -r release-2-0-3 qm</tt>
</li>
</ul>
</p></li>
<p>These are needed to use the LLVM test suite.</p></li>
</ul>
@@ -327,7 +317,7 @@ of this document below</i>. In any of the examples below, simply replace
each of these names with the appropriate pathname on your local system.
All these paths are absolute:</p>
<dl>
<dl compact>
<dt>SRC_ROOT
<dd>
This is the top level directory of the LLVM source tree.
@@ -363,7 +353,7 @@ variables. There are also some shell aliases which you may find useful.
You can set these on the command line, or better yet, set them in your
<tt>.cshrc</tt> or <tt>.profile</tt>.
<dl>
<dl compact>
<dt><tt>LLVM_LIB_SEARCH_PATH</tt>=<tt><i>LLVMGCCDIR</i>/bytecode-libs</tt>
<dd>
This environment variable helps the LLVM GCC front end find bytecode
@@ -381,7 +371,7 @@ You can set these on the command line, or better yet, set them in your
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="unpack">Unpacking the LLVM Archives</a>
<a name="unpack">Unpacking the LLVM Archives</a></h3>
</div>
<div class="doc_text">
@@ -394,24 +384,24 @@ file is a TAR archive that is compressed with the gzip program.
</p>
<p> The files are as follows:
<dl>
<dt>llvm-1.2.tar.gz
<dl compact>
<dt>llvm-1.1.tar.gz
<dd>This is the source code to the LLVM suite.
<p>
<dt>cfrontend-1.2.sparc-sun-solaris2.8.tar.gz
<dt>cfrontend-1.1.sparc-sun-solaris2.8.tar.gz
<dd>This is the binary release of the GCC front end for Solaris/Sparc.
<p>
<dt>cfrontend-1.2.i686-redhat-linux-gnu.tar.gz
<dt>cfrontend-1.1.i686-redhat-linux-gnu.tar.gz
<dd>This is the binary release of the GCC front end for Linux/x86.
<p>
<dt>cfrontend-1.2.i386-unknown-freebsd5.1.tar.gz
<dt>cfrontend-1.1.i386-unknown-freebsd5.1.tar.gz
<dd>This is the binary release of the GCC front end for FreeBSD/x86.
<p>
<dt>cfrontend-1.2.powerpc-apple-darwin7.0.0.tar.gz
<dt>cfrontend-1.1.powerpc-apple-darwin7.0.0.tar.gz
<dd>This is the binary release of the GCC front end for MacOS X/PPC.
</dl>
@@ -419,7 +409,7 @@ file is a TAR archive that is compressed with the gzip program.
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="checkout">Checkout LLVM from CVS</a>
<a name="checkout">Checkout LLVM from CVS</a></h3>
</div>
<div class="doc_text">
@@ -440,15 +430,10 @@ follows:</p>
directory and fully populate it with the LLVM source code, Makefiles,
test directories, and local copies of documentation files.</p>
<p>If you want to get a specific release (as opposed to the most recent
revision), you can specify a label. The following releases have the following
label:</p>
<p>
If you want to get a specific release (as opposed to the most recent revision),
you can specify a label. The following releases have the following label:
<ul>
<li>
Release 1.2: <b>RELEASE_12</b>
</li>
<li>
Release 1.1: <b>RELEASE_11</b>
</li>
@@ -457,21 +442,16 @@ label:</p>
Release 1.0: <b>RELEASE_1</b>
</li>
</ul>
<p>
If you would like to get the GCC front end source code, you can also get it
from the CVS repository:
<ul>
<li><tt>cvs -z3 -d :pserver:anon@llvm-cvs.cs.uiuc.edu:/var/cvs/llvm co
llvm-gcc</tt>
</ul>
</p>
<p>Note that the GCC front end is not included in the CVS repository. You
should have downloaded the binary distribution for your platform.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="installcf">Install the GCC Front End</a>
<a name="installcf">Install the GCC Front End</a></h3>
</div>
<div class="doc_text">
@@ -492,7 +472,7 @@ location must be specified when the LLVM suite is configured.</p>
<p>If you are using Solaris/Sparc or MacOS X/PPC, you will need to fix the
header files:</p>
<p><tt>cd cfrontend/<i>platform</i><br>
<p><tt>cd cfrontend/sparc<br>
./fixheaders</tt></p>
<p>The binary versions of the GCC front end may not suit all of your needs. For
@@ -547,10 +527,10 @@ script to configure the build system:</p>
<p>The following options can be used to set or enable LLVM specific options:</p>
<dl>
<dl compact>
<dt><i>--with-llvmgccdir=LLVMGCCDIR</i>
<dd>
Path to the location where the LLVM GCC front end binaries and
Path to the location where the LLVM C front end binaries and
associated libraries were installed. This must be specified as an
absolute pathname.
<p>
@@ -576,19 +556,6 @@ script to configure the build system:</p>
benchmarks. If <tt>directory</tt> is left unspecified, <tt>configure</tt>
uses the default value
<tt>/home/vadve/shared/benchmarks/speccpu2000/benchspec</tt>.
<p>
<dt><i>--enable-spec95</i>
<dt><i>--enable-spec95=&lt;<tt>directory</tt>&gt;</i>
<dd>
Enable the use of SPEC95 when testing LLVM. It is similar to the
<i>--enable-spec2000</i> option.
<p>
<dt><i>--enable-povray</i>
<dt><i>--enable-povray=&lt;<tt>directory</tt>&gt;</i>
<dd>
Enable the use of Povray as an external test. Versions of Povray written
in C should work. This option is similar to the <i>--enable-spec2000</i>
option.
</dl>
<p>To configure LLVM, follow these steps:</p>
@@ -627,7 +594,7 @@ version of the GCC front end on our research machines.</p>
<p>Once you have configured LLVM, you can build it. There are three types of
builds:</p>
<dl>
<dl compact>
<dt>Debug Builds
<dd>
These builds are the default when one types <tt>gmake</tt> (unless the
@@ -667,7 +634,7 @@ command:</p>
<p>There are several special targets which are useful when working with the LLVM
source code:</p>
<dl>
<dl compact>
<dt><tt>gmake clean</tt>
<dd>
Removes all files generated by the build. This includes object files,
@@ -694,7 +661,7 @@ source code:</p>
<p>It is also possible to override default values from <tt>configure</tt> by
declaring variables on the command line. The following are some examples:</p>
<dl>
<dl compact>
<dt><tt>gmake ENABLE_OPTIMIZED=1</tt>
<dd>
Perform a Release (Optimized) build.
@@ -745,10 +712,10 @@ platforms or configurations using the same source tree.</p>
<p>The LLVM build will place files underneath <i>OBJ_ROOT</i> in directories
named after the build type:</p>
<dl>
<dl compact>
<dt>Debug Builds
<dd>
<dl>
<dl compact>
<dt>Tools
<dd><tt><i>OBJ_ROOT</i>/tools/Debug</tt>
<dt>Libraries
@@ -758,7 +725,7 @@ named after the build type:</p>
<dt>Release Builds
<dd>
<dl>
<dl compact>
<dt>Tools
<dd><tt><i>OBJ_ROOT</i>/tools/Release</tt>
<dt>Libraries
@@ -768,7 +735,7 @@ named after the build type:</p>
<dt>Profile Builds
<dd>
<dl>
<dl compact>
<dt>Tools
<dd><tt><i>OBJ_ROOT</i>/tools/Profile</tt>
<dt>Libraries
@@ -787,7 +754,7 @@ named after the build type:</p>
<div class="doc_text">
<p>One useful source of information about the LLVM source base is the LLVM <a
href="http://www.doxygen.org">doxygen</a> documentation available at <tt><a
href="http://www.doxygen.org">doxygen</a> documentation, available at <tt><a
href="http://llvm.cs.uiuc.edu/doxygen/">http://llvm.cs.uiuc.edu/doxygen/</a></tt>.
The following is a brief introduction to code layout:</p>
@@ -846,7 +813,7 @@ library. The three main subdirectories of this directory are:</p>
almost all code exists in libraries, making it very easy to share code among the
different <a href="#tools">tools</a>.</p>
<dl>
<dl compact>
<dt><tt>llvm/lib/VMCore/</tt><dd> This directory holds the core LLVM
source files that implement core classes like Instruction and BasicBlock.
@@ -871,7 +838,7 @@ different <a href="#tools">tools</a>.</p>
<dt><tt>llvm/lib/Target/</tt><dd> This directory contains files that
describe various target architectures for code generation. For example,
the llvm/lib/Target/SparcV9 directory holds the Sparc machine
the llvm/lib/Target/Sparc directory holds the Sparc machine
description.<br>
<dt><tt>llvm/lib/CodeGen/</tt><dd> This directory contains the major parts
@@ -924,30 +891,33 @@ the LLVM infrastructure.</p>
<p>The <b>tools</b> directory contains the executables built out of the
libraries above, which form the main part of the user interface. You can
always get help for a tool by typing <tt>tool_name --help</tt>. The
following is a brief introduction to the most important tools:</p>
following is a brief introduction to the most important tools.</p>
<dl>
<dt><tt><b>analyze</b></tt> <dd><tt>analyze</tt> is used to run a specific
<dl compact>
<dt>
<dt><tt><b>analyze</b></tt><dd> <tt>analyze</tt> is used to run a specific
analysis on an input LLVM bytecode file and print out the results. It is
primarily useful for debugging analyses, or familiarizing yourself with
what an analysis does.<p>
<dt><tt><b>bugpoint</b></tt> <dd><tt>bugpoint</tt> is used to debug
<dt><tt><b>bugpoint</b></tt><dd> <tt>bugpoint</tt> is used to debug
optimization passes or code generation backends by narrowing down the
given test case to the minimum number of passes and/or instructions that
still cause a problem, whether it is a crash or miscompilation. See <a
href="HowToSubmitABug.html">HowToSubmitABug.html</a> for more information
on using <tt>bugpoint</tt>.<p>
<dt><tt><b>llvm-ar</b></tt> <dd>The archiver produces an archive containing
<dt><tt><b>llvm-ar</b></tt><dd>The archiver produces an archive containing
the given LLVM bytecode files, optionally with an index for faster
lookup.<p>
<dt><tt><b>llvm-as</b></tt> <dd>The assembler transforms the human readable
<dt><tt><b>llvm-as</b></tt><dd>The assembler transforms the human readable
LLVM assembly to LLVM bytecode.<p>
<dt><tt><b>llvm-dis</b></tt><dd>The disassembler transforms the LLVM
bytecode to human readable LLVM assembly.<p>
bytecode to human readable LLVM assembly. Additionally, it can convert
LLVM bytecode to C, which is enabled with the <tt>-c</tt> option.<p>
<dt><tt><b>llvm-link</b></tt><dd> <tt>llvm-link</tt>, not surprisingly,
links multiple LLVM modules into a single program.<p>
@@ -961,9 +931,8 @@ following is a brief introduction to the most important tools:</p>
functionality was compiled in), and will execute the code <i>much</i>
faster than the interpreter.<p>
<dt><tt><b>llc</b></tt><dd> <tt>llc</tt> is the LLVM backend compiler, which
translates LLVM bytecode to a SPARC or x86 assembly file, or to C code (with
the -march=c option).<p>
<dt><tt><b>llc</b></tt><dd> <tt>llc</tt> is the LLVM backend compiler,
which translates LLVM bytecode to a SPARC or x86 assembly file.<p>
<dt><tt><b>llvmgcc</b></tt><dd> <tt>llvmgcc</tt> is a GCC-based C frontend
that has been retargeted to emit LLVM code as the machine code output. It
@@ -972,9 +941,8 @@ following is a brief introduction to the most important tools:</p>
<tt>llvmgcc</tt> tool is currently not included in the LLVM CVS tree
because it is quite large and not very interesting.<p>
<blockquote>
<dl>
<dt><tt><b>gccas</b></tt> <dd>This tool is invoked by the
<ol>
<dt><tt><b>gccas</b></tt><dd> This tool is invoked by the
<tt>llvmgcc</tt> frontend as the "assembler" part of the compiler. This
tool actually assembles LLVM assembly to LLVM bytecode,
performs a variety of optimizations, and outputs LLVM bytecode. Thus
@@ -986,19 +954,19 @@ following is a brief introduction to the most important tools:</p>
`<tt>as</tt>' utility so that the gcc frontend itself did not have to be
modified to interface to a "weird" assembler.<p>
<dt><tt><b>gccld</b></tt> <dd><tt>gccld</tt> links together several LLVM
<dt><tt><b>gccld</b></tt><dd> <tt>gccld</tt> links together several LLVM
bytecode files into one bytecode file and does some optimization. It is
the linker invoked by the GCC frontend when multiple .o files need to be
linked together. Like <tt>gccas</tt>, the command line interface of
<tt>gccld</tt> is designed to match the system linker, to aid
interfacing with the GCC frontend.</dl><p>
</blockquote>
interfacing with the GCC frontend.<p>
</ol>
<dt><tt><b>opt</b></tt><dd> <tt>opt</tt> reads LLVM bytecode, applies a
series of LLVM to LLVM transformations (which are specified on the command
line), and then outputs the resultant bytecode. The '<tt>opt --help</tt>'
command is a good way to get a list of the program transformations
available in LLVM.
available in LLVM.<p>
</dl>
@@ -1015,19 +983,19 @@ following is a brief introduction to the most important tools:</p>
of the utilities are actually required as part of the build process because they
are code generators for parts of LLVM infrastructure.</p>
<dl>
<dt><tt><b>Burg/</b></tt> <dd><tt>Burg</tt> is an instruction selector
<dl compact>
<td><tt><b>Burg/</b></tt><dd> <tt>Burg</tt> is an instruction selector
generator -- it builds trees on which it then performs pattern-matching to
select instructions according to the patterns the user has specified. Burg
is currently used in the Sparc V9 backend.<p>
<dt><tt><b>codegen-diff</b></tt> <dd><tt>codegen-diff</tt> is a script
<dt><tt><b>codegen-diff</b></tt><dd> <tt>codegen-diff</tt> is a script
that finds differences between code that LLC generates and code that LLI
generates. This is a useful tool if you are debugging one of them,
assuming that the other generates correct output. For the full user
manual, run <tt>`perldoc codegen-diff'</tt>.<p>
<dt><tt><b>cvsupdate</b></tt> <dd><tt>cvsupdate</tt> is a script that will
<dt><tt><b>cvsupdate</b></tt><dd> <tt>cvsupdate</tt> is a script that will
update your CVS tree, but produce a much cleaner and more organized output
than simply running <tt>`cvs -z3 up -dP'</tt> will. For example, it will group
together all the new and updated files and modified files in separate
@@ -1035,20 +1003,20 @@ are code generators for parts of LLVM infrastructure.</p>
top of your LLVM CVS tree, running <tt>utils/cvsupdate</tt> is the
preferred way of updating the tree.<p>
<dt><tt><b>emacs/</b></tt> <dd>The <tt>emacs</tt> directory contains
<dt><tt><b>emacs/</b></tt><dd> The <tt>emacs</tt> directory contains
syntax-highlighting files which will work with Emacs and XEmacs editors,
providing syntax highlighting support for LLVM assembly files and TableGen
description files. For information on how to use the syntax files, consult
the <tt>README</tt> file in that directory.<p>
<dt><tt><b>getsrcs.sh</b></tt> <dd>The <tt>getsrcs.sh</tt> script finds
<dt><tt><b>getsrcs.sh</b></tt><dd> The <tt>getsrcs.sh</tt> script finds
and outputs all non-generated source files, which is useful if one wishes
to do a lot of development across directories and does not want to
individually find each file. One way to use it is to run, for example:
<tt>xemacs `utils/getsources.sh`</tt> from the top of your LLVM source
tree.<p>
<dt><tt><b>makellvm</b></tt> <dd>The <tt>makellvm</tt> script compiles all
<dt><tt><b>makellvm</b></tt><dd> The <tt>makellvm</tt> script compiles all
files in the current directory and then compiles and links the tool that
is the first argument. For example, assuming you are in the directory
<tt>llvm/lib/Target/Sparc</tt>, if <tt>makellvm</tt> is in your path,
@@ -1057,17 +1025,17 @@ are code generators for parts of LLVM infrastructure.</p>
causing a re-linking of LLC.<p>
<dt><tt><b>NightlyTest.pl</b></tt> and
<tt><b>NightlyTestTemplate.html</b></tt> <dd>These files are used in a
<tt><b>NightlyTestTemplate.html</b></tt><dd> These files are used in a
cron script to generate nightly status reports of the functionality of
tools, and the results can be seen by following the appropriate link on
the <a href="http://llvm.cs.uiuc.edu/">LLVM homepage</a>.<p>
<dt><tt><b>TableGen/</b></tt> <dd>The <tt>TableGen</tt> directory contains
<dt><tt><b>TableGen/</b></tt><dd> The <tt>TableGen</tt> directory contains
the tool used to generate register descriptions, instruction set
descriptions, and even assemblers from common TableGen description
files.<p>
<dt><tt><b>vim/</b></tt> <dd>The <tt>vim</tt> directory contains
<dt><tt><b>vim/</b></tt><dd> The <tt>vim</tt> directory contains
syntax-highlighting files which will work with the VIM editor, providing
syntax highlighting support for LLVM assembly files and TableGen
description files. For information on how to use the syntax files, consult
@@ -1176,11 +1144,6 @@ out:</p>
<hr>
<address>
<a href="http://jigsaw.w3.org/css-validator/check/referer"><img
src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
<a href="http://validator.w3.org/check/referer"><img
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
<a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
Last modified: $Date$

View File

@@ -11,6 +11,8 @@
How to submit an LLVM bug report
</div>
<div>
<table border="0" width="100%">
<tr>
<td valign="top">
@@ -29,14 +31,12 @@
</ol>
<div class="doc_text">
<p><b>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a> and
<a href="http://misha.brukman.net">Misha Brukman</a></b></p>
</div>
<p><b>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a> and
<a href="http://misha.brukman.net">Misha Brukman</a></b></p>
</td>
<td align="right">
<img src="Debugging.gif" alt="Debugging" width="444" height="314">
<img src="Debugging.gif" width="444" height="314">
</td>
</tr>
</table>
@@ -96,14 +96,12 @@ buggy or if it's one of the LLVM tools that has problems.</p>
<tt><b>gccas</b></tt>, or <tt><b>gccld</b></tt>), run the
<tt><b>llvm-gcc</b></tt> command line as you were when the crash occurred, but
add a <tt>-v</tt> option to the command line. The compiler will print out a
bunch of stuff, and should end with telling you that one of
<tt><b>cc1</b>/<b>cc1plus</b></tt>, <tt><b>gccas</b></tt>, or
<tt><b>gccld</b></tt> crashed.</p>
bunch of stuff, and should end with telling you that one of <tt><b>cc1</b></tt>,
<tt><b>gccas</b></tt>, or <tt><b>gccld</b></tt> crashed.</p>
<ul>
<li>If <tt><b>cc1</b></tt> or <tt><b>cc1plus</b></tt> crashed, you found a
problem with the front-end.
<li>If <tt><b>cc1</b></tt> crashed, you found a problem with the front-end.
Jump ahead to the section on <a href="#front-end">front-end bugs</a>.</li>
<li>If <tt><b>gccas</b></tt> crashed, you found a bug in <a href="#gccas">one
@@ -283,7 +281,7 @@ the following:</p>
<li>Regenerate the shared object from the safe bytecode file:<br>
<pre>
<b>llc</b> -march=c safe.bc -o safe.c<br>
<b>llvm-dis</b> -c safe.bc -o safe.c<br>
<b>gcc</b> -shared safe.c -o safe.so
</pre></li>
@@ -295,8 +293,8 @@ the following:</p>
./test.llc [program options]
</pre></li>
<li>If debugging the JIT, load the shared object and supply the test
bytecode:
<p>If debugging the JIT, load the shared object and supply the test
bytecode:</p>
<pre>
<b>lli</b> -load=safe.so test.bc [program options]
@@ -307,18 +305,14 @@ bytecode:
</div>
<!-- *********************************************************************** -->
<hr>
<address>
<a href="http://jigsaw.w3.org/css-validator/check/referer"><img
src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
<a href="http://validator.w3.org/check/referer"><img
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
<a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
<hr>
<div class="doc_footer">
<address><a href="mailto:sabre@nondot.org">Chris Lattner</a></address>
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
<br>
Last modified: $Date$
</address>
</div>
</body>
</html>

View File

@@ -1,5 +1,4 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>LLVM Assembly Language Reference Manual</title>
@@ -80,7 +79,6 @@
<ol>
<li><a href="#i_phi">'<tt>phi</tt>' Instruction</a></li>
<li><a href="#i_cast">'<tt>cast .. to</tt>' Instruction</a></li>
<li><a href="#i_select">'<tt>select</tt>' Instruction</a></li>
<li><a href="#i_call">'<tt>call</tt>' Instruction</a></li>
<li><a href="#i_vanext">'<tt>vanext</tt>' Instruction</a></li>
<li><a href="#i_vaarg">'<tt>vaarg</tt>' Instruction</a></li>
@@ -97,20 +95,6 @@
<li><a href="#i_va_copy">'<tt>llvm.va_copy</tt>' Intrinsic</a></li>
</ol>
</li>
<li><a href="#int_codegen">Code Generator Intrinsics</a>
<ol>
<li><a href="#i_returnaddress">'<tt>llvm.returnaddress</tt>' Intrinsic</a></li>
<li><a href="#i_frameaddress">'<tt>llvm.frameaddress</tt>' Intrinsic</a></li>
</ol>
</li>
<li><a href="#int_libc">Standard C Library Intrinsics</a>
<ol>
<li><a href="#i_memcpy">'<tt>llvm.memcpy</tt>' Intrinsic</a></li>
<li><a href="#i_memmove">'<tt>llvm.memmove</tt>' Intrinsic</a></li>
<li><a href="#i_memset">'<tt>llvm.memset</tt>' Intrinsic</a></li>
</ol>
</li>
<li><a href="#int_debugger">Debugger intrinsics</a>
</ol>
</li>
</ol>
@@ -189,7 +173,7 @@ character can be used in a name.</li>
<li>Unnamed values are represented as an unsigned numeric value with
a '%' prefix. For example, %12, %2, %44.</li>
</ol>
<p>LLVM requires that values start with a '%' sign for two reasons:
<p>LLVM requires the values start with a '%' sign for two reasons:
Compilers don't need to worry about name clashes with reserved words,
and the set of reserved words may be expanded in the future without
penalty. Additionally, unnamed identifiers allow a compiler to quickly
@@ -257,12 +241,12 @@ href="#rw_stroustrup">1</a></sup>.<p> --> </div>
<div class="doc_text">
<p>The primitive types are the fundemental building blocks of the LLVM
system. The current set of primitive types are as follows:</p>
<table border="0" style="align: center">
<p>
<table border="0" align="center">
<tbody>
<tr>
<td>
<table border="1" cellspacing="0" cellpadding="4" style="align: center">
<table border="1" cellspacing="0" cellpadding="4" align="center">
<tbody>
<tr>
<td><tt>void</tt></td>
@@ -296,7 +280,7 @@ system. The current set of primitive types are as follows:</p>
</table>
</td>
<td valign="top">
<table border="1" cellspacing="0" cellpadding="4">
<table border="1" cellspacing="0" cellpadding="4" align="center&quot;">
<tbody>
<tr>
<td><tt>bool</tt></td>
@@ -328,7 +312,7 @@ system. The current set of primitive types are as follows:</p>
</tr>
</tbody>
</table>
</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="t_classifications">Type
@@ -336,8 +320,8 @@ Classifications</a> </div>
<div class="doc_text">
<p>These different primitive types fall into a few useful
classifications:</p>
<table border="1" cellspacing="0" cellpadding="4">
<p>
<table border="1" cellspacing="0" cellpadding="4" align="center">
<tbody>
<tr>
<td><a name="t_signed">signed</a></td>
@@ -366,7 +350,7 @@ uint, int, ulong, long, float, double, <a href="#t_pointer">pointer</a></tt></td
</tr>
</tbody>
</table>
</p>
<p>The <a href="#t_firstclass">first class</a> types are perhaps the
most important. Values of these types are the only ones which can be
produced by instructions, passed as arguments, or used as operands to
@@ -398,7 +382,7 @@ be any type with a size.</p>
<tt>[40 x uint]</tt>: Array of 40 unsigned integer values.</p>
<p> </p>
<p>Here are some examples of multidimensional arrays:</p>
<p>
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
@@ -415,7 +399,7 @@ be any type with a size.</p>
</tr>
</tbody>
</table>
</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="t_function">Function Type</a> </div>
@@ -437,7 +421,7 @@ which indicates that the function takes a variable number of arguments.
Variable argument functions can access their arguments with the <a
href="#int_varargs">variable argument handling intrinsic</a> functions.</p>
<h5>Examples:</h5>
<p>
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
@@ -459,7 +443,7 @@ in LLVM.</td>
</tr>
</tbody>
</table>
</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="t_struct">Structure Type</a> </div>
@@ -476,7 +460,7 @@ instruction.</p>
<h5>Syntax:</h5>
<pre> { &lt;type list&gt; }<br></pre>
<h5>Examples:</h5>
<p>
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
@@ -492,7 +476,7 @@ an <tt>int</tt>.</td>
</tr>
</tbody>
</table>
</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="t_pointer">Pointer Type</a> </div>
@@ -503,7 +487,7 @@ reference to another object, which must live in memory.</p>
<h5>Syntax:</h5>
<pre> &lt;type&gt; *<br></pre>
<h5>Examples:</h5>
<p>
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
@@ -519,7 +503,7 @@ an <tt>int</tt>.</td>
</tr>
</tbody>
</table>
</p>
</div>
<!-- _______________________________________________________________________ --><!--
<div class="doc_subsubsection">
@@ -574,7 +558,7 @@ this case, a pointer to an array of char, and a pointer to a function),
and have one of the following linkage types:</a>
<p> </p>
<dl>
<dt><tt><b><a name="linkage_internal">internal</a></b></tt> </dt>
<a name="linkage_internal"> <dt><tt><b>internal</b></tt> </dt>
<dd>Global values with internal linkage are only directly accessible
by objects in the current module. In particular, linking code into a
module with an internal global value may cause the internal to be
@@ -584,7 +568,7 @@ corresponds to the notion of the '<tt>static</tt>' keyword in C, or the
idea of "anonymous namespaces" in C++.
<p> </p>
</dd>
<dt><tt><b><a name="linkage_linkonce">linkonce</a></b></tt>: </dt>
</a><a name="linkage_linkonce"> <dt><tt><b>linkonce</b></tt>: </dt>
<dd>"<tt>linkonce</tt>" linkage is similar to <tt>internal</tt>
linkage, with the twist that linking together two modules defining the
same <tt>linkonce</tt> globals will cause one of the globals to be
@@ -592,14 +576,14 @@ discarded. This is typically used to implement inline functions.
Unreferenced <tt>linkonce</tt> globals are allowed to be discarded.
<p> </p>
</dd>
<dt><tt><b><a name="linkage_weak">weak</a></b></tt>: </dt>
</a><a name="linkage_weak"> <dt><tt><b>weak</b></tt>: </dt>
<dd>"<tt>weak</tt>" linkage is exactly the same as <tt>linkonce</tt>
linkage, except that unreferenced <tt>weak</tt> globals may not be
discarded. This is used to implement constructs in C such as "<tt>int
X;</tt>" at global scope.
<p> </p>
</dd>
<dt><tt><b><a name="linkage_appending">appending</a></b></tt>: </dt>
</a><a name="linkage_appending"> <dt><tt><b>appending</b></tt>: </dt>
<dd>"<tt>appending</tt>" linkage may only be applied to global
variables of pointer to array type. When two global variables with
appending linkage are linked together, the two global arrays are
@@ -608,12 +592,13 @@ the system linker append together "sections" with identical names when
.o files are linked.
<p> </p>
</dd>
<dt><tt><b><a name="linkage_external">externally visible</a></b></tt>:</dt>
</a><a name="linkage_external"> <dt><tt><b>externally visible</b></tt>:</dt>
<dd>If none of the above identifiers are used, the global is
externally visible, meaning that it participates in linkage and can be
used to resolve external symbol references.
<p> </p>
</dd>
</a>
</dl>
<p> </p>
<p><a name="linkage_external">For example, since the "<tt>.LC0</tt>"
@@ -624,61 +609,45 @@ external (i.e., lacking any linkage declarations), they are accessible
outside of the current module. It is illegal for a function <i>declaration</i>
to have any linkage type other than "externally visible".</a></p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="globalvars">Global Variables</a>
</div>
<div class="doc_subsection"> <a name="globalvars">Global Variables</a> </div>
<div class="doc_text">
<p>Global variables define regions of memory allocated at compilation
time instead of run-time. Global variables may optionally be
initialized. A variable may be defined as a global "constant", which
indicates that the contents of the variable will never be modified
(opening options for optimization).</p>
(opening options for optimization). Constants must always have an
initial value.</p>
<p>As SSA values, global variables define pointer values that are in
scope (i.e. they dominate) for all basic blocks in the program. Global
variables always define a pointer to their "content" type because they
describe a region of memory, and all memory objects in LLVM are
accessed through pointers.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="functionstructure">Functions</a>
</div>
<div class="doc_subsection"> <a name="functionstructure">Functions</a> </div>
<div class="doc_text">
<p>LLVM function definitions are composed of a (possibly empty) argument list,
an opening curly brace, a list of basic blocks, and a closing curly brace. LLVM
function declarations are defined with the "<tt>declare</tt>" keyword, a
function name, and a function signature.</p>
<p>A function definition contains a list of basic blocks, forming the CFG for
the function. Each basic block may optionally start with a label (giving the
basic block a symbol table entry), contains a list of instructions, and ends
with a <a href="#terminators">terminator</a> instruction (such as a branch or
function return).</p>
<p>The first basic block in program is special in two ways: it is immediately
executed on entrance to the function, and it is not allowed to have predecessor
basic blocks (i.e. there can not be any branches to the entry block of a
function). Because the block can have no predecessors, it also cannot have any
<a href="#i_phi">PHI nodes</a>.</p>
<p>LLVM functions are identified by their name and type signature. Hence, two
functions with the same name but different parameter lists or return values are
considered different functions, and LLVM will resolves references to each
appropriately.</p>
<p>LLVM function definitions are composed of a (possibly empty)
argument list, an opening curly brace, a list of basic blocks, and a
closing curly brace. LLVM function declarations are defined with the "<tt>declare</tt>"
keyword, a function name, and a function signature.</p>
<p>A function definition contains a list of basic blocks, forming the
CFG for the function. Each basic block may optionally start with a
label (giving the basic block a symbol table entry), contains a list of
instructions, and ends with a <a href="#terminators">terminator</a>
instruction (such as a branch or function return).</p>
<p>The first basic block in program is special in two ways: it is
immediately executed on entrance to the function, and it is not allowed
to have predecessor basic blocks (i.e. there can not be any branches to
the entry block of a function). Because the block can have no
predecessors, it also cannot have any <a href="#i_phi">PHI nodes</a>.</p>
<p>
LLVM functions are identified by their name and type signature. Hence, two
functions with the same name but different parameter lists or return values
are considered different functions, and LLVM will resolves references to each
appropriately.
</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section"> <a name="instref">Instruction Reference</a> </div>
<!-- *********************************************************************** -->
@@ -765,61 +734,40 @@ control flows to the '<tt>iffalse</tt>' <tt>label</tt> argument.</p>
href="#i_ret">ret</a> int 1<br>IfUnequal:<br> <a href="#i_ret">ret</a> int 0<br></pre>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="i_switch">'<tt>switch</tt>' Instruction</a>
</div>
<div class="doc_subsubsection"> <a name="i_switch">'<tt>switch</tt>'
Instruction</a> </div>
<div class="doc_text">
<h5>Syntax:</h5>
<pre>
switch &lt;intty&gt; &lt;value&gt;, label &lt;defaultdest&gt; [ &lt;intty&gt; &lt;val&gt;, label &lt;dest&gt; ... ]
</pre>
<pre> switch uint &lt;value&gt;, label &lt;defaultdest&gt; [ int &lt;val&gt;, label &amp;dest&gt;, ... ]<br></pre>
<h5>Overview:</h5>
<p>The '<tt>switch</tt>' instruction is used to transfer control flow to one of
several different places. It is a generalization of the '<tt>br</tt>'
<p>The '<tt>switch</tt>' instruction is used to transfer control flow
to one of several different places. It is a generalization of the '<tt>br</tt>'
instruction, allowing a branch to occur to one of many possible
destinations.</p>
<h5>Arguments:</h5>
<p>The '<tt>switch</tt>' instruction uses three parameters: an integer
comparison value '<tt>value</tt>', a default '<tt>label</tt>' destination, and
an array of pairs of comparison value constants and '<tt>label</tt>'s. The
table is not allowed to contain duplicate constant entries.</p>
<p>The '<tt>switch</tt>' instruction uses three parameters: a '<tt>uint</tt>'
comparison value '<tt>value</tt>', a default '<tt>label</tt>'
destination, and an array of pairs of comparison value constants and '<tt>label</tt>'s.</p>
<h5>Semantics:</h5>
<p>The <tt>switch</tt> instruction specifies a table of values and
destinations. When the '<tt>switch</tt>' instruction is executed, this
table is searched for the given value. If the value is found, the
corresponding destination is branched to, otherwise the default value
it transfered to.</p>
<h5>Implementation:</h5>
<p>Depending on properties of the target machine and the particular
<tt>switch</tt> instruction, this instruction may be code generated in different
ways, for example as a series of chained conditional branches, or with a lookup
table.</p>
<p>Depending on properties of the target machine and the particular <tt>switch</tt>
instruction, this instruction may be code generated as a series of
chained conditional branches, or with a lookup table.</p>
<h5>Example:</h5>
<pre> <i>; Emulate a conditional br instruction</i>
%Val = <a
href="#i_cast">cast</a> bool %value to uint<br> switch uint %Val, label %truedest [int 0, label %falsedest ]<br><br> <i>; Emulate an unconditional br instruction</i>
switch uint 0, label %dest [ ]
<pre>
<i>; Emulate a conditional br instruction</i>
%Val = <a href="#i_cast">cast</a> bool %value to int
switch int %Val, label %truedest [int 0, label %falsedest ]
<i>; Emulate an unconditional br instruction</i>
switch uint 0, label %dest [ ]
<i>; Implement a jump table:</i>
switch uint %val, label %otherwise [ uint 0, label %onzero
uint 1, label %onone
uint 2, label %ontwo ]
<i>; Implement a jump table:</i>
switch uint %val, label %otherwise [ int 0, label %onzero,
int 1, label %onone,
int 2, label %ontwo ]
</pre>
</div>
<!-- _______________________________________________________________________ -->
@@ -1083,7 +1031,7 @@ identical types.</p>
<h5>Semantics:</h5>
<p>The truth table used for the '<tt>and</tt>' instruction is:</p>
<p> </p>
<div style="align: center">
<center>
<table border="1" cellspacing="0" cellpadding="4">
<tbody>
<tr>
@@ -1113,7 +1061,7 @@ identical types.</p>
</tr>
</tbody>
</table>
</div>
</center>
<h5>Example:</h5>
<pre> &lt;result&gt; = and int 4, %var <i>; yields {int}:result = 4 &amp; %var</i>
&lt;result&gt; = and int 15, 40 <i>; yields {int}:result = 8</i>
@@ -1136,7 +1084,7 @@ identical types.</p>
<h5>Semantics:</h5>
<p>The truth table used for the '<tt>or</tt>' instruction is:</p>
<p> </p>
<div style="align: center">
<center>
<table border="1" cellspacing="0" cellpadding="4">
<tbody>
<tr>
@@ -1166,7 +1114,7 @@ identical types.</p>
</tr>
</tbody>
</table>
</div>
</center>
<h5>Example:</h5>
<pre> &lt;result&gt; = or int 4, %var <i>; yields {int}:result = 4 | %var</i>
&lt;result&gt; = or int 15, 40 <i>; yields {int}:result = 47</i>
@@ -1191,7 +1139,7 @@ identical types.</p>
<h5>Semantics:</h5>
<p>The truth table used for the '<tt>xor</tt>' instruction is:</p>
<p> </p>
<div style="align: center">
<center>
<table border="1" cellspacing="0" cellpadding="4">
<tbody>
<tr>
@@ -1221,7 +1169,7 @@ identical types.</p>
</tr>
</tbody>
</table>
</div>
</center>
<p> </p>
<h5>Example:</h5>
<pre> &lt;result&gt; = xor int 4, %var <i>; yields {int}:result = 4 ^ %var</i>
@@ -1300,8 +1248,8 @@ Instruction</a> </div>
<p>The '<tt>malloc</tt>' instruction allocates memory from the system
heap and returns a pointer to it.</p>
<h5>Arguments:</h5>
<p>The '<tt>malloc</tt>' instruction allocates <tt>sizeof(&lt;type&gt;)*NumElements</tt>
bytes of memory from the operating system and returns a pointer of the
<p>The the '<tt>malloc</tt>' instruction allocates <tt>sizeof(&lt;type&gt;)*NumElements</tt>
bytes of memory from the operating system, and returns a pointer of the
appropriate type to the program. The second form of the instruction is
a shorter version of the first instruction that defaults to allocating
one element.</p>
@@ -1507,111 +1455,38 @@ came from in the last <a href="#terminators">terminator</a> instruction.</p>
<h5>Example:</h5>
<pre>Loop: ; Infinite loop that counts from 0 on up...<br> %indvar = phi uint [ 0, %LoopHeader ], [ %nextindvar, %Loop ]<br> %nextindvar = add uint %indvar, 1<br> br label %Loop<br></pre>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="i_cast">'<tt>cast .. to</tt>' Instruction</a>
</div>
<div class="doc_subsubsection"> <a name="i_cast">'<tt>cast .. to</tt>'
Instruction</a> </div>
<div class="doc_text">
<h5>Syntax:</h5>
<pre>
&lt;result&gt; = cast &lt;ty&gt; &lt;value&gt; to &lt;ty2&gt; <i>; yields ty2</i>
<pre> &lt;result&gt; = cast &lt;ty&gt; &lt;value&gt; to &lt;ty2&gt; <i>; yields ty2</i>
</pre>
<h5>Overview:</h5>
<p>
The '<tt>cast</tt>' instruction is used as the primitive means to convert
integers to floating point, change data type sizes, and break type safety (by
casting pointers).
</p>
<p>The '<tt>cast</tt>' instruction is used as the primitive means to
convert integers to floating point, change data type sizes, and break
type safety (by casting pointers).</p>
<h5>Arguments:</h5>
<p>
The '<tt>cast</tt>' instruction takes a value to cast, which must be a first
class value, and a type to cast it to, which must also be a <a
href="#t_firstclass">first class</a> type.
</p>
<p>The '<tt>cast</tt>' instruction takes a value to cast, which must be
a first class value, and a type to cast it to, which must also be a <a
href="#t_firstclass">first class</a> type.</p>
<h5>Semantics:</h5>
<p>
This instruction follows the C rules for explicit casts when determining how the
data being cast must change to fit in its new container.
</p>
<p>
When casting to bool, any value that would be considered true in the context of
a C '<tt>if</tt>' condition is converted to the boolean '<tt>true</tt>' values,
all else are '<tt>false</tt>'.
</p>
<p>
When extending an integral value from a type of one signness to another (for
example '<tt>sbyte</tt>' to '<tt>ulong</tt>'), the value is sign-extended if the
<b>source</b> value is signed, and zero-extended if the source value is
unsigned. <tt>bool</tt> values are always zero extended into either zero or
one.
</p>
<p>This instruction follows the C rules for explicit casts when
determining how the data being cast must change to fit in its new
container.</p>
<p>When casting to bool, any value that would be considered true in the
context of a C '<tt>if</tt>' condition is converted to the boolean '<tt>true</tt>'
values, all else are '<tt>false</tt>'.</p>
<p>When extending an integral value from a type of one signness to
another (for example '<tt>sbyte</tt>' to '<tt>ulong</tt>'), the value
is sign-extended if the <b>source</b> value is signed, and
zero-extended if the source value is unsigned. <tt>bool</tt> values
are always zero extended into either zero or one.</p>
<h5>Example:</h5>
<pre>
%X = cast int 257 to ubyte <i>; yields ubyte:1</i>
<pre> %X = cast int 257 to ubyte <i>; yields ubyte:1</i>
%Y = cast int 123 to bool <i>; yields bool:true</i>
</pre>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="i_select">'<tt>select</tt>' Instruction</a>
</div>
<div class="doc_text">
<h5>Syntax:</h5>
<pre>
&lt;result&gt; = select bool &lt;cond&gt;, &lt;ty&gt; &lt;val1&gt;, &lt;ty&gt; &lt;val2&gt; <i>; yields ty</i>
</pre>
<h5>Overview:</h5>
<p>
The '<tt>select</tt>' instruction is used to choose one value based on a
condition, without branching.
</p>
<h5>Arguments:</h5>
<p>
The '<tt>select</tt>' instruction requires a boolean value indicating the condition, and two values of the same <a href="#t_firstclass">first class</a> type.
</p>
<h5>Semantics:</h5>
<p>
If the boolean condition evaluates to true, the instruction returns the first
value argument, otherwise it returns the second value argument.
</p>
<h5>Example:</h5>
<pre>
%X = select bool true, ubyte 17, ubyte 42 <i>; yields ubyte:17</i>
</pre>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="i_call">'<tt>call</tt>'
Instruction</a> </div>
@@ -1712,44 +1587,31 @@ an argument.</p>
<p>See the <a href="#int_varargs">variable argument processing</a>
section.</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section"> <a name="intrinsics">Intrinsic Functions</a> </div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>LLVM supports the notion of an "intrinsic function". These functions have
well known names and semantics, and are required to follow certain
restrictions. Overall, these instructions represent an extension mechanism for
the LLVM language that does not require changing all of the transformations in
LLVM to add to the language (or the bytecode reader/writer, the parser,
etc...).</p>
<p>Intrinsic function names must all start with an "<tt>llvm.</tt>" prefix, this
prefix is reserved in LLVM for intrinsic names, thus functions may not be named
this. Intrinsic functions must always be external functions: you cannot define
the body of intrinsic functions. Intrinsic functions may only be used in call
or invoke instructions: it is illegal to take the address of an intrinsic
function. Additionally, because intrinsic functions are part of the LLVM
language, it is required that they all be documented here if any are added.</p>
<p>
Adding an intrinsic to LLVM is straight-forward if it is possible to express the
concept in LLVM directly (ie, code generator support is not _required_). To do
this, extend the default implementation of the IntrinsicLowering class to handle
the intrinsic. Code generators use this class to lower intrinsics they do not
understand to raw LLVM instructions that they do.
</p>
<p>LLVM supports the notion of an "intrinsic function". These
functions have well known names and semantics, and are required to
follow certain restrictions. Overall, these instructions represent an
extension mechanism for the LLVM language that does not require
changing all of the transformations in LLVM to add to the language (or
the bytecode reader/writer, the parser, etc...).</p>
<p>Intrinsic function names must all start with an "<tt>llvm.</tt>"
prefix, this prefix is reserved in LLVM for intrinsic names, thus
functions may not be named this. Intrinsic functions must always be
external functions: you cannot define the body of intrinsic functions.
Intrinsic functions may only be used in call or invoke instructions: it
is illegal to take the address of an intrinsic function. Additionally,
because intrinsic functions are part of the LLVM language, it is
required that they all be documented here if any are added.</p>
<p>Unless an intrinsic function is target-specific, there must be a
lowering pass to eliminate the intrinsic or all backends must support
the intrinsic function.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="int_varargs">Variable Argument Handling Intrinsics</a>
</div>
<div class="doc_subsection"> <a name="int_varargs">Variable Argument
Handling Intrinsics</a> </div>
<div class="doc_text">
<p>Variable argument support is defined in LLVM with the <a
href="#i_vanext"><tt>vanext</tt></a> instruction and these three
@@ -1763,34 +1625,15 @@ used.</p>
<p>This example shows how the <a href="#i_vanext"><tt>vanext</tt></a>
instruction and the variable argument handling intrinsic functions are
used.</p>
<pre>
int %test(int %X, ...) {
; Initialize variable argument processing
%ap = call sbyte* %<a href="#i_va_start">llvm.va_start</a>()
; Read a single integer argument
%tmp = vaarg sbyte* %ap, int
; Advance to the next argument
%ap2 = vanext sbyte* %ap, int
; Demonstrate usage of llvm.va_copy and llvm.va_end
%aq = call sbyte* %<a href="#i_va_copy">llvm.va_copy</a>(sbyte* %ap2)
call void %<a href="#i_va_end">llvm.va_end</a>(sbyte* %aq)
; Stop processing of arguments.
call void %<a href="#i_va_end">llvm.va_end</a>(sbyte* %ap2)
ret int %tmp
}
</pre>
<pre>int %test(int %X, ...) {<br> ; Initialize variable argument processing<br> %ap = call sbyte*()* %<a
href="#i_va_start">llvm.va_start</a>()<br><br> ; Read a single integer argument<br> %tmp = vaarg sbyte* %ap, int<br><br> ; Advance to the next argument<br> %ap2 = vanext sbyte* %ap, int<br><br> ; Demonstrate usage of llvm.va_copy and llvm.va_end<br> %aq = call sbyte* (sbyte*)* %<a
href="#i_va_copy">llvm.va_copy</a>(sbyte* %ap2)<br> call void %<a
href="#i_va_end">llvm.va_end</a>(sbyte* %aq)<br><br> ; Stop processing of arguments.<br> call void %<a
href="#i_va_end">llvm.va_end</a>(sbyte* %ap2)<br> ret int %tmp<br>}<br></pre>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="i_va_start">'<tt>llvm.va_start</tt>' Intrinsic</a>
</div>
<div class="doc_subsubsection"> <a name="i_va_start">'<tt>llvm.va_start</tt>'
Intrinsic</a> </div>
<div class="doc_text">
<h5>Syntax:</h5>
<pre> call va_list ()* %llvm.va_start()<br></pre>
@@ -1807,12 +1650,9 @@ last argument of the function, the compiler can figure that out.</p>
<p>Note that this intrinsic function is only legal to be called from
within the body of a variable argument function.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="i_va_end">'<tt>llvm.va_end</tt>' Intrinsic</a>
</div>
<div class="doc_subsubsection"> <a name="i_va_end">'<tt>llvm.va_end</tt>'
Intrinsic</a> </div>
<div class="doc_text">
<h5>Syntax:</h5>
<pre> call void (va_list)* %llvm.va_end(va_list &lt;arglist&gt;)<br></pre>
@@ -1829,12 +1669,9 @@ Calls to <a href="#i_va_start"><tt>llvm.va_start</tt></a> and <a
href="#i_va_copy"><tt>llvm.va_copy</tt></a> must be matched exactly
with calls to <tt>llvm.va_end</tt>.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="i_va_copy">'<tt>llvm.va_copy</tt>' Intrinsic</a>
</div>
<div class="doc_subsubsection"> <a name="i_va_copy">'<tt>llvm.va_copy</tt>'
Intrinsic</a> </div>
<div class="doc_text">
<h5>Syntax:</h5>
<pre> call va_list (va_list)* %llvm.va_copy(va_list &lt;destarglist&gt;)<br></pre>
@@ -1850,305 +1687,11 @@ element into the returned list. This intrinsic is necessary because the <tt><a
href="i_va_start">llvm.va_start</a></tt> intrinsic may be arbitrarily
complex and require memory allocation, for example.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="int_codegen">Code Generator Intrinsics</a>
</div>
<div class="doc_text">
<p>
These intrinsics are provided by LLVM to expose special features that may only
be implemented with code generator support.
</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="i_returnaddress">'<tt>llvm.returnaddress</tt>' Intrinsic</a>
</div>
<div class="doc_text">
<h5>Syntax:</h5>
<pre>
call void* ()* %llvm.returnaddress(uint &lt;level&gt;)
</pre>
<h5>Overview:</h5>
<p>
The '<tt>llvm.returnaddress</tt>' intrinsic returns a target-specific value
indicating the return address of the current function or one of its callers.
</p>
<h5>Arguments:</h5>
<p>
The argument to this intrinsic indicates which function to return the address
for. Zero indicates the calling function, one indicates its caller, etc. The
argument is <b>required</b> to be a constant integer value.
</p>
<h5>Semantics:</h5>
<p>
The '<tt>llvm.returnaddress</tt>' intrinsic either returns a pointer indicating
the return address of the specified call frame, or zero if it cannot be
identified. The value returned by this intrinsic is likely to be incorrect or 0
for arguments other than zero, so it should only be used for debugging purposes.
</p>
<p>
Note that calling this intrinsic does not prevent function inlining or other
aggressive transformations, so the value returned may not that of the obvious
source-language caller.
</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="i_frameaddress">'<tt>llvm.frameaddress</tt>' Intrinsic</a>
</div>
<div class="doc_text">
<h5>Syntax:</h5>
<pre>
call void* ()* %llvm.frameaddress(uint &lt;level&gt;)
</pre>
<h5>Overview:</h5>
<p>
The '<tt>llvm.frameaddress</tt>' intrinsic returns the target-specific frame
pointer value for the specified stack frame.
</p>
<h5>Arguments:</h5>
<p>
The argument to this intrinsic indicates which function to return the frame
pointer for. Zero indicates the calling function, one indicates its caller,
etc. The argument is <b>required</b> to be a constant integer value.
</p>
<h5>Semantics:</h5>
<p>
The '<tt>llvm.frameaddress</tt>' intrinsic either returns a pointer indicating
the frame address of the specified call frame, or zero if it cannot be
identified. The value returned by this intrinsic is likely to be incorrect or 0
for arguments other than zero, so it should only be used for debugging purposes.
</p>
<p>
Note that calling this intrinsic does not prevent function inlining or other
aggressive transformations, so the value returned may not that of the obvious
source-language caller.
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="int_libc">Standard C Library Intrinsics</a>
</div>
<div class="doc_text">
<p>
LLVM provides intrinsics for a few important standard C library functions.
These intrinsics allow source-language front-ends to pass information about the
alignment of the pointer arguments to the code generator, providing opportunity
for more efficient code generation.
</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="i_memcpy">'<tt>llvm.memcpy</tt>' Intrinsic</a>
</div>
<div class="doc_text">
<h5>Syntax:</h5>
<pre>
call void (sbyte*, sbyte*, uint, uint)* %llvm.memcpy(sbyte* &lt;dest&gt;, sbyte* &lt;src&gt;,
uint &lt;len&gt;, uint &lt;align&gt;)
</pre>
<h5>Overview:</h5>
<p>
The '<tt>llvm.memcpy</tt>' intrinsic copies a block of memory from the source
location to the destination location.
</p>
<p>
Note that, unlike the standard libc function, the <tt>llvm.memcpy</tt> intrinsic
does not return a value, and takes an extra alignment argument.
</p>
<h5>Arguments:</h5>
<p>
The first argument is a pointer to the destination, the second is a pointer to
the source. The third argument is an (arbitrarily sized) integer argument
specifying the number of bytes to copy, and the fourth argument is the alignment
of the source and destination locations.
</p>
<p>
If the call to this intrinisic has an alignment value that is not 0 or 1, then
the caller guarantees that the size of the copy is a multiple of the alignment
and that both the source and destination pointers are aligned to that boundary.
</p>
<h5>Semantics:</h5>
<p>
The '<tt>llvm.memcpy</tt>' intrinsic copies a block of memory from the source
location to the destination location, which are not allowed to overlap. It
copies "len" bytes of memory over. If the argument is known to be aligned to
some boundary, this can be specified as the fourth argument, otherwise it should
be set to 0 or 1.
</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="i_memmove">'<tt>llvm.memmove</tt>' Intrinsic</a>
</div>
<div class="doc_text">
<h5>Syntax:</h5>
<pre>
call void (sbyte*, sbyte*, uint, uint)* %llvm.memmove(sbyte* &lt;dest&gt;, sbyte* &lt;src&gt;,
uint &lt;len&gt;, uint &lt;align&gt;)
</pre>
<h5>Overview:</h5>
<p>
The '<tt>llvm.memmove</tt>' intrinsic moves a block of memory from the source
location to the destination location. It is similar to the '<tt>llvm.memcpy</tt>'
intrinsic but allows the two memory locations to overlap.
</p>
<p>
Note that, unlike the standard libc function, the <tt>llvm.memmove</tt> intrinsic
does not return a value, and takes an extra alignment argument.
</p>
<h5>Arguments:</h5>
<p>
The first argument is a pointer to the destination, the second is a pointer to
the source. The third argument is an (arbitrarily sized) integer argument
specifying the number of bytes to copy, and the fourth argument is the alignment
of the source and destination locations.
</p>
<p>
If the call to this intrinisic has an alignment value that is not 0 or 1, then
the caller guarantees that the size of the copy is a multiple of the alignment
and that both the source and destination pointers are aligned to that boundary.
</p>
<h5>Semantics:</h5>
<p>
The '<tt>llvm.memmove</tt>' intrinsic copies a block of memory from the source
location to the destination location, which may overlap. It
copies "len" bytes of memory over. If the argument is known to be aligned to
some boundary, this can be specified as the fourth argument, otherwise it should
be set to 0 or 1.
</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
<a name="i_memset">'<tt>llvm.memset</tt>' Intrinsic</a>
</div>
<div class="doc_text">
<h5>Syntax:</h5>
<pre>
call void (sbyte*, ubyte, uint, uint)* %llvm.memset(sbyte* &lt;dest&gt;, ubyte &lt;val&gt;,
uint &lt;len&gt;, uint &lt;align&gt;)
</pre>
<h5>Overview:</h5>
<p>
The '<tt>llvm.memset</tt>' intrinsic fills a block of memory with a particular
byte value.
</p>
<p>
Note that, unlike the standard libc function, the <tt>llvm.memset</tt> intrinsic
does not return a value, and takes an extra alignment argument.
</p>
<h5>Arguments:</h5>
<p>
The first argument is a pointer to the destination to fill, the second is the
byte value to fill it with, the third argument is an (arbitrarily sized) integer
argument specifying the number of bytes to fill, and the fourth argument is the
known alignment of destination location.
</p>
<p>
If the call to this intrinisic has an alignment value that is not 0 or 1, then
the caller guarantees that the size of the copy is a multiple of the alignment
and that the destination pointer is aligned to that boundary.
</p>
<h5>Semantics:</h5>
<p>
The '<tt>llvm.memset</tt>' intrinsic fills "len" bytes of memory starting at the
destination location. If the argument is known to be aligned to some boundary,
this can be specified as the fourth argument, otherwise it should be set to 0 or
1.
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="int_debugger">Debugger Intrinsics</a>
</div>
<div class="doc_text">
<p>
The LLVM debugger intrinsics (which all start with <tt>llvm.dbg.</tt> prefix),
are described in the <a
href="SourceLevelDebugging.html#format_common_intrinsics">LLVM Source Level
Debugging</a> document.
</p>
</div>
<!-- *********************************************************************** -->
<hr>
<address>
<a href="http://jigsaw.w3.org/css-validator/check/referer"><img
src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
<a href="http://validator.w3.org/check/referer"><img
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
<a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
Last modified: $Date$
</address>
<div class="doc_footer">
<address><a href="mailto:sabre@nondot.org">Chris Lattner</a></address>
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a> <br>
Last modified: $Date$ </div>
</body>
</html>

View File

@@ -1,298 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html>
<head>
<title>Object Files: Understanding The Result Of LLVM Compilation</title>
<link rel="stylesheet" href="llvm.css" type="text/css">
</head>
<body>
<div class="doc_title">Object Files: Understanding The Result Of LLVM Compilation</div>
<hr>
<ol>
<li><a href="#abstract">Abstract</a></li>
<li><a href="#introduction">Introduction</a></li>
<li><a href="#files">File Contents</a></li>
<li><a href="#rot">Linkage Rules Of Thumb</a>
<ol>
<li><a href="#always">Always Link vmcore.o, support.a</a>
<li><a href="#placeholder">Placeholder</a>
</ol>
</li>
</ol>
<div class="doc_text">
<p><b>Written by <a href="mailto:rspencer@x10sys.com">Reid Spencer</a> </b></p>
<p> </p>
</div>
<hr>
<!-- ======================================================================= -->
<div class="doc_section"><a name="abstract">Abstract</a></div>
<div class="doc_text">
<p>This document describes the contents of the many objects files and libraries
that are produced by compiling LLVM. To make use of LLVM this information is
needed in order to understand what files should be linked into your program.
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_section"> <a name="introduction">Introduction</a></div>
<div class="doc_text">
<p>If you're writing a compiler, virtual machine, or any other utility for
LLVM, you'll need to figure out which of the many .a (archive) and .o
(object) files you will need to link with to be successful. An
understanding of the contents of these files and their inter-relationships
will be useful in coming up with an optimal specification for the objects
and libraries to link with.
</p>
<p>The purpose of this document is to hopefully reduce some of the trial and
error that the author experienced in using LLVM.
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_section"><a name="files"></a>File Contents</div>
<div class="doc_text">
<p>The table below provides a summary of the basic contents of each file.</p>
<table class="doc_table"
style="width:80%; text-align: left; border: 2px solid blue; border-collapse: collapse;">
<tr class="doc_table">
<td colspan="2" class="doc_section">Summary Of LLVM Library And Object Files
</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue"><h2><u>Library</u></h2></td>
<td style="border: 2px solid blue"><h2><u>Description</u></h2></td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">libipo.a</td>
<td style="border: 2px solid blue">
An archive of all inter-procedural optimizations.
</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">libscalaropts.a</td>
<td style="border: 2px solid blue">
An archive of all scalar optimizations.
</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">libtransforms.a</td>
<td style="border: 2px solid blue">
An archive of just the level raise pass.
</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">libtarget.a</td>
<td style="border: 2px solid blue">
An archive containing code generator support for describing
target architectures.
</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">libanalysis.a</td>
<td style="border: 2px solid blue">
An archive containing intra-procedural analyses.
</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">libdatastructure.a</td>
<td style="border: 2px solid blue">
An archive containing optimizations for data structures.
</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">libinstrument.a</td>
<td style="border: 2px solid blue">No idea.</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">libregalloc.a</td>
<td style="border: 2px solid blue">Register Allocation code.</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">libipa.a</td>
<td style="border: 2px solid blue">
An archive containing inter-procedural analyses</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">libtransformutils.a</td>
<td style="border: 2px solid blue">
Utiltities for transformations?
</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">libsupport.a</td>
<td style="border: 2px solid blue">General support utilities</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">libevar.a</td>
<td style="border: 2px solid blue">Live variable analysis for SPARC</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue"><h2><u>Object File</u></h2></td>
<td style="border: 2px solid blue"><h2><u>Description</u></h2></td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">support.o</td>
<td style="border: 2px solid blue">General support utilities</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">asmparser.o</td>
<td style="border: 2px solid blue">Assembler Parser</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">bcreader.o</td>
<td style="border: 2px solid blue">Byte Code Reader</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">bcwriter.o</td>
<td style="border: 2px solid blue">Byte Code Writer</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">sched.o</td>
<td style="border: 2px solid blue">SPARC instruction scheduler</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">selectiondag.o</td>
<td style="border: 2px solid blue">Aggressive instruction selector for Directed Acyclic Graphs</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">transformutils.o</td>
<td style="border: 2px solid blue">Utilities for code transformations</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">ipa.o</td>
<td style="border: 2px solid blue">Inter-Procedural Analysis Optimizations</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">select.o</td>
<td style="border: 2px solid blue">SPARC instruction selector</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">cwriter.o</td>
<td style="border: 2px solid blue">"C" Code Writer</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">profpaths.o</td>
<td style="border: 2px solid blue">Path profiling instrumentation</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">regalloc.o</td>
<td style="border: 2px solid blue">Register Allocation</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">instrument.o</td>
<td style="border: 2px solid blue">Instrumentation? Of What?</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">datastructure.o</td>
<td style="border: 2px solid blue">Data Structure Analysis</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">codegen.o</td>
<td style="border: 2px solid blue">Native code generation</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">livevar.o</td>
<td style="border: 2px solid blue">Live Variable Analysis</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">vmcore.o</td>
<td style="border: 2px solid blue">Virtual Machine Core</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">lli-interpreter.o</td>
<td style="border: 2px solid blue">Interpreter for LLVM ByteCode</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">lli-jit.o</td>
<td style="border: 2px solid blue">
Just-In-Time Compiler For LLVM ByteCode
</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">executionengine.o</td>
<td style="border: 2px solid blue">Engine for LLI</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">debugger.o</td>
<td style="border: 2px solid blue">Source Level Debugging Support</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">analysis.o</td>
<td style="border: 2px solid blue">General Framework For Analysis?</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">sparc.o</td>
<td style="border: 2px solid blue">Sun SPARC Processor Specific</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">target.o</td>
<td style="border: 2px solid blue">Target Machine Support?</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">transforms.o</td>
<td style="border: 2px solid blue">Code Transformations</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">x86.o</td>
<td style="border: 2px solid blue">Intel x86 Processor Specific</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">powerpc.o</td>
<td style="border: 2px solid blue">PowerPC Processor Specific</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">scalaropts.o</td>
<td style="border: 2px solid blue">Optimizations For Scalars</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">ipo.o</td>
<td style="border: 2px solid blue">Inter-Procedural Optimization</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">trace.o</td>
<td style="border: 2px solid blue">Support For Tracing/Debugging?</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">profile_rt.o</td>
<td style="border: 2px solid blue">Runtime Library For Profiler</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">sample.o</td>
<td style="border: 2px solid blue">Sample Program ?</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">stkr_compiler.o</td>
<td style="border: 2px solid blue">Stacker Language Compiler Library</td>
</tr>
<tr class="doc_table">
<td style="border: 2px solid blue">stkr_runtime.o</td>
<td style="border: 2px solid blue">Stacker Language Runtime Library</td>
</tr>
</table>
</div>
<p></p>
<!-- ======================================================================= -->
<div class="doc_section"><a name="rot">Linkage Rules Of Thumb</a></div>
<div class="doc_text">
<p>This section contains various "rules of thumb" about what files you
should link into your programs.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="always">Always Link vmcore.o support.a</a>
</div>
<div class="doc_text">
<p>No matter what you do with LLVM, you'll always need to link with vmcore.o
and support.a.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="Placeholder">Placeholder</a></div>
<div class="doc_text">
<p>Need more rules of thumb here.</p>
</div>
<!-- ======================================================================= -->
<hr>
<div class="doc_footer">
<address><a href="mailto:rspencer@x10sys.com">Reid Spencer</a></address>
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
<br>Last modified: $Date$ </div>
</body>
</html>
<!-- vim: sw=2 ts=2 ai
-->

View File

@@ -52,16 +52,9 @@ contributions.</p>
to the <a href="http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVM
Developer's</a> mailing list, so that we know the project is being worked on.
Additionally this is a good way to get more information about a specific project
or to suggest other projects to add to this page.
</p>
<p>The projects in this page are open ended. More specific projects are
filed as unassigned enhancements in our <a href="http://llvm.cs.uiuc.edu/bugs/">
LLVM bug tracker</a>. Here is the current list:
</p>
<iframe src="http://llvm.cs.uiuc.edu/bugs/buglist.cgi?keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=enhancement&emailassigned_to1=1&emailtype1=substring&email1=unassigned" frameborder="1" align="center" width="100%" height="400">
</iframe>
or to suggest other projects to add to this page. Another good place to look
for ideas is the <a href="http://llvm.cs.uiuc.edu/bugs/">LLVM bug
tracker</a>.</p>
</div>
@@ -108,6 +101,10 @@ library and the <tt>stdio</tt> related functions... low-level system calls like
daily report. It could use the following improvements:</p>
<ol>
<li>Graphs - It would be great to have gnuplot graphs to keep track of how the
tree is changing over time. We already gather a several statistics, it
just necessary to add the script-fu to gnuplotize it.</li>
<li>Regression tests - We should run the regression tests in addition to the
program tests...</li>
</ol>
@@ -143,6 +140,10 @@ all the back-ends: CBE, llc, and lli.</p>
<div class="doc_text">
<ol>
<li>Add a new conditional move instruction: <tt>X = select bool Cond, Y,
Z</tt></li>
<li>Add support for platform-independent prefetch support. The GCC <a
href="http://gcc.gnu.org/projects/prefetch.html">prefetch project</a> page
has a good survey of the prefetching capabilities of a variety of modern
@@ -165,6 +166,11 @@ all the back-ends: CBE, llc, and lli.</p>
would also then have to implement the reader for this index in
<tt>gccld</tt>.</li>
<li>Improve the efficiency of the bytecode loader/writer</li>
<li>Extend the FunctionPassManager to use a ModuleProvider to stream functions
in on demand. This would improve the efficiency of the JIT.</li>
<li>Rework the PassManager to be more flexible</li>
<li>Some transformations and analyses only work on reducible flow graphs. It
@@ -232,11 +238,11 @@ themselves. It seems natural to want to take advantage of this...</p>
<div class="doc_text">
<p>We now have a unified infrastructure for writing profile-guided
transformations, which will work either at offline-compile-time or in the JIT,
but we don't have many transformations. We would welcome new profile-guided
transformations as well as improvements to the current profiling system.
</p>
<p>We are getting to the point where we really need a unified infrastructure for
profile guided optimizations. It would be wonderful to be able to write profile
guided transformations which can be performed either at static compile time
(compile time or offline optimization time) or at runtime in a JIT type setup.
The LLVM transformation itself shouldn't need to know how it is being used.</p>
<p>Ideas for profile guided transformations:</p>
@@ -248,23 +254,6 @@ transformations as well as improvements to the current profiling system.
<li>...</li>
</ol>
<p>Improvements to the existing support:</p>
<ol>
<li>The current block and edge profiling code that gets inserted is very simple
and inefficient. Through the use of control-dependence information, many fewer
counters could be inserted into the code. Also, if the execution count of a
loop is known to be a compile-time or runtime constant, all of the counters in
the loop could be avoided.</li>
<li>You could implement one of the "static profiling" algorithms which analyze a
piece of code an make educated guesses about the relative execution frequencies
of various parts of the code.</li>
<li>You could add path profiling support, or adapt the existing LLVM path
profiling code to work with the generic profiling interfaces.</li>
</ol>
</div>
<!-- ======================================================================= -->
@@ -277,6 +266,8 @@ profiling code to work with the generic profiling interfaces.</li>
<ol>
<li>Implement a Dependence Analysis Infrastructure<br>
- Design some way to represent and query dep analysis</li>
<li>Implement a faster Dominator Set Construction Algorithm<br>
- A linear time or nearly so algorithm</li>
<li>Implement a strength reduction pass</li>
<li>Value range propagation pass</li>
<li>Implement an unswitching pass</li>
@@ -302,7 +293,7 @@ profiling code to work with the generic profiling interfaces.</li>
</div>
<!-- ======================================================================= -->
<div class="doc_section">
<div class="doc_subsection">
<a name="misc_new">Miscellaneous Additions</a>
</div>
@@ -311,11 +302,6 @@ profiling code to work with the generic profiling interfaces.</li>
<ol>
<li>Write a new frontend for some language (Java? OCaml? Forth?)</li>
<li>Write a new backend for a target (IA64? MIPS? MMIX?)</li>
<li>Random test vector generator: Use a C grammar to generate random C code;
run it through llvm-gcc, then run a random set of passes on it using opt.
Try to crash opt. When opt crashes, use bugpoint to reduce the test case and
mail the result to yourself. Repeat ad infinitum.</li>
<li>Design a simple, recognizable logo.</li>
</ol>
</div>

File diff suppressed because it is too large Load Diff

View File

@@ -3,13 +3,11 @@
<html>
<head>
<link rel="stylesheet" href="llvm.css" type="text/css">
<title>LLVM 1.2 Release Notes</title>
<title>LLVM 1.1 Release Notes</title>
</head>
<body>
<div class="doc_title">
LLVM 1.2 Release Notes
</div>
<div class="doc_title">LLVM 1.1 Release Notes</div>
<ol>
<li><a href="#intro">Introduction</a></li>
@@ -18,7 +16,6 @@
<li><a href="#install-instructions">Installation Instructions</a></li>
<li><a href="#knownproblems">Known Problems</a>
<ul>
<li><a href="#experimental">Experimental features included with this release</a>
<li><a href="#core">Known problems with the LLVM Core</a>
<li><a href="#c-fe">Known problems with the C Front-end</a>
<li><a href="#c++-fe">Known problems with the C++ Front-end</a>
@@ -42,10 +39,10 @@
<div class="doc_text">
<p>This document contains the release notes for the LLVM compiler
infrastructure, release 1.2. Here we describe the status of LLVM, including any
infrastructure, release 1.1. Here we describe the status of LLVM, including any
known problems and bug fixes from the previous release. The most up-to-date
version of this document can be found on the <a
href="http://llvm.cs.uiuc.edu/releases/1.2/">LLVM 1.2 web site</a>. If you are
href="http://llvm.cs.uiuc.edu/releases/1.1/">LLVM 1.1 web site</a>. If you are
not reading this on the LLVM web pages, you should probably go there because
this document may be updated after the release.</p>
@@ -70,70 +67,93 @@ href="http://llvm.cs.uiuc.edu/releases/">releases page</a>.</p>
<div class="doc_text">
<p>
This is the third public release of the LLVM compiler infrastructure. This
release incorporates several <a href="#newfeatures">new features</a> (including
exception handling support for the native code generators, the start of a
source-level debugger, and profile guided optimizer components), many <a
href="#qualityofimp">speedups</a> and <a href="#codequality">code quality</a>
improvements, documentation improvements, and a small collection of important <a
href="bugfix">bug fixes</a>. Overall, this is our highest quality release to
date, and we encourage you to upgrade if you are using LLVM 1.0 or 1.1.
<p>This is the second public release of the LLVM compiler infrastructure. This
release is primarily a bugfix release, dramatically improving the C/C++
front-end and improving support for C++ in the LLVM core. This release also
includes a few new features, such as a simple profiler, support for Mac OS X,
better interoperability with external source bases, a new example language
front-end, and improvements in a few optimizations. The performance of several
LLVM components has been improved, and several gratuitous type-safety issues in
the C front-end have been fixed.</p>
<p>At this time, LLVM is known to correctly compile and run all non-unwinding C
&amp; C++ SPEC CPU2000 benchmarks, the Olden benchmarks, and the Ptrdist
benchmarks. It has also been used to compile <b>many</b> other programs. LLVM
now also works with a broad variety of C++ programs, though it has still
received much less testing than the C front-end.
</p>
<p>
At this time, LLVM is known to correctly compile and run all C &amp; C++ SPEC
CPU2000 benchmarks, the Olden benchmarks, and the Ptrdist benchmarks. It has
also been used to compile <b>many</b> other programs. LLVM now also works with
a broad variety of C++ programs, though it has still received less testing than
the C front-end.
The LLVM native code generators are very stable but do not currently support
unwinding (exception throwing or <tt>longjmp</tt>ing), which prevent them from
working with programs like the <tt>253.perlbmk</tt> in SPEC CPU2000. The C
backend and the rest of LLVM supports these programs, so you can
still use LLVM with them. Support for unwinding will be added in a future
release.
</p>
<!--=========================================================================-->
<div class="doc_subsubsection">
<a name="newfeatures">This release implements the following new features:</a>
This release implements the following new features:
</div>
<ol>
<li><a href="SourceLevelDebugging.html">A new LLVM source-level debugger has been started.</a></li>
<li>LLVM 1.2 encodes bytecode files for large programs in 10-30% less space.</li>
<li>LLVM can now feed profile information back into optimizers for Profile Guided Optimization, includes a simple basic block reordering pass, and supports edge profiling as well as function and block-level profiling.</li>
<li>The LLVM JIT lazily initializes global variables, reducing startup time for programs with lots of globals (like C++ programs).</li>
<li><a
href="http://mail.cs.uiuc.edu/pipermail/llvmdev/2003-November/000528.html">A new
LLVM profiler, similar to gprof,</a> is available.</li>
<li>The build and installation infrastructure in this release is dramatically
improved. There is now an <a
href="http://llvm.cs.uiuc.edu/PR105"><tt>autoconf/AutoRegen.sh</tt> script</a>
that you can run to rebuild the <tt>configure</tt> script and its associated
files as well as beta support for "<a
href="http://llvm.cs.uiuc.edu/PR208">make</a> <a
href="http://llvm.cs.uiuc.edu/PR220">install</a>" and <a
href="http://llvm.cs.uiuc.edu/PR203">RPM package generation</a>.</li>
<li>LLVM and the C/C++ front-end now compile on Mac OS X! Mac OS X users can
now explore the LLVM optimizer with the C backend and interpreter. Note that
LLVM requires GCC 3.3 on Mac OS X.</li>
<li>The "tblgen" tool is <a href="TableGenFundamentals.html">now documented</a>.</li>
<li>The target-independent code generator got several improvements:
<ul>
<li>It can now fold spill code into instructions (on targets that support it).</li>
<li>A generic machine code spiller/rewriter was added. It provides an API for
global register allocators to eliminate virtual registers and add the
appropriate spill code.</li>
<li>The represenation of machine code basic blocks is more efficient and has
an easier to use interface.</li>
</ul>
<li>LLVM has been <a
href="http://mail.cs.uiuc.edu/pipermail/llvmdev/2003-November/000554.html">moved
into an 'llvm' C++ namespace</a> for easier integration with third-party
code. Note that due to lack of namespace support in GDB 5.x, you will probably
want to upgrade to GDB 6 or better to debug LLVM code.</li>
<li>
The build system now copies Makefiles dynamically from the source tree to the
object tree as subdirectories are built. This means that:
<ol>
<li>
New directories can be added to the source tree, and the build will
automatically pick them up (i.e. no need to edit <tt>configure.ac</tt> and
re-run <tt>configure</tt>).
</li>
<li>
You will need to build LLVM from the top of the object tree once to ensure
that all of the Makefiles are copied into the object tree subdirectories.
</li>
</ol>
</li>
<li><a href="http://llvm.cs.uiuc.edu/PR253">LLVM now no longer depends on the boost library</a>.</li>
<li>The X86 backend now generates <b>substantially</b> better native code and is faster.</li>
<li>The C backend has been turned moved from the "llvm-dis" tool to the "llc"
tool. You can activate it with "<tt>llc -march=c foo.bc -o foo.c</tt>".</li>
<li>LLVM includes a new interprocedural optimization that marks global variables
"constant" when they are provably never written to.</li>
<li>LLVM now includes a new interprocedural optimization that converts small "by reference" arguments to "by value" arguments, which often improves the performance of C++ programs substantially.</li>
<li>Bugpoint can now do a better job reducing miscompilation problems by
reducing programs down to a particular loop nest, instead of just the function
being miscompiled.</li>
<li>The GCSE and LICM passes can now operate on side-effect-free function calls, for example hoisting calls to "<tt>strlen</tt>" and folding "<tt>cos</tt>" common subexpressions.</li>
<li>LLVM has early support for a new <a
href="LangRef.html#i_select"><tt>select</tt></a> instruction, though it is
currently only supported by the C backend.</li>
<li>A front-end for "Stacker" (a simple Forth-like language) is now
<a href="http://llvm.cs.uiuc.edu/PR136">included in the main LLVM tree</a>.
Additionally, Reid Spencer, the author, contributed a document
<a href="Stacker.html">describing his experiences writing Stacker and the language itself</a>.
This document is invaluable for others writing front-ends targetting LLVM.</li>
<li>The <tt>configure</tt> script will now configure all projects placed in the
<tt>llvm/projects</tt> directory.</li>
<li>The <tt>-tailcallelim</tt> pass can now introduce "accumulator" variables
to transform functions in many common cases that it could not before.</li>
<li>The <tt>-licm</tt> pass can now sink instructions out the bottom of loops
in addition to being able to hoist them out the top.</li>
<li>The <tt>-basicaa</tt> pass (the default alias analysis pass) has been
upgraded to be <a href="http://llvm.cs.uiuc.edu/PR86">significantly more
precise</a>.</li>
<li>LLVM 1.1 implements a simple size optimization for LLVM bytecode files.
This means that the 1.1 files are smaller than 1.0, but LLVM 1.0 won't
read 1.1 bytecode files.</li>
<li><a href="http://llvm.cs.uiuc.edu/PR140">The gccld program produces a runner script that includes command-line options to load the necessary shared objects.</a></li>
</ol>
@@ -143,113 +163,135 @@ In this release, the following missing features were implemented:
</div>
<ol>
<li><a href="http://llvm.cs.uiuc.edu/PR16">Exception handling in the X86
&amp; Sparc native code generators</a> is now supported</li>
<li>The C/C++ front-end now supports the GCC <tt>__builtin_return_address</tt> and <tt>__builtin_frame_address</tt> extensions. These are also supported by the X86 backend and by the C backend.</li>
<li><a href="http://llvm.cs.uiuc.edu/PR249">[X86] Missing cast from ULong -> Double, cast FP -> bool and support for -9223372036854775808</a></li>
<li>The C/C++ front-end <a href="http://llvm.cs.uiuc.edu/PR273">now supports</a>
the "<a href="http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html#Labels%20as%20Values">labels as values</a>" GCC extension, often used to build "threaded interpreters".</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR88">The interpreter does not support
invoke or unwind</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR99">Interpreter does not support the
<tt>vaarg</tt> instruction</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR117">llvm-nm cannot read archive
files</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR146">Interpreter does not handle
setne constant expression</a></li>
</ol>
<!--=========================================================================-->
<div class="doc_subsubsection">
<a name="qualityofimp">In this release, the following Quality of Implementation issues were fixed:</a>
In this release, the following Quality of Implementation issues were
fixed:
</div>
<ol>
<li><a href="http://llvm.cs.uiuc.edu/PR135">JIT should lazily initialize global variables</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR192">[X86] X86 Backend never releases memory for machine code structures</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR196">[vmcore] OpaqueType objects memory leak</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR182">[llvmgcc] C front-end does not compile "extern inline" into linkonce</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR73">Bytecode format inconsistent</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR209">[loadvn/inline/scalarrepl] Slow optimizations with extremely large basic blocks</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR224">[asmparser] Really slow parsing of types with complex upreferences</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR205">[llvmgcc] C front-end does not emit 'zeroinitializer' when possible</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR233">[llvmgcc] Structure copies result in a LOT of code</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR239">LLVM is now much more memory efficient when handling large zero initialized arrays</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR275">[llvmgcc] Local array initializers are expanded into large amounts of code</a></li>
</ol>
<li>The C++ front-end now compiles functions to
<a href="http://llvm.cs.uiuc.edu/PR29">use the linkonce linkage type</a>
more, giving the optimizer more freedom.</li>
<!--=========================================================================-->
<div class="doc_subsubsection">
In this release, the following build problems were fixed:
</div>
<li>The C front-end now <a href="http://llvm.cs.uiuc.edu/PR84">generates
type-safe code</a> in several cases that it did not before, allowing
optimization of code that could not be optimized previously.</li>
<ol>
<li><a href="http://llvm.cs.uiuc.edu/PR210">[build] Makefiles break if C frontend target string has unexpected value</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR214">[build] hard-wired assumption that shared-library extension is ".so"</a></li>
<li><A href="http://llvm.cs.uiuc.edu/PR222">make tools-only doesn't make lib/Support</a></li>
</ol>
<li>The LLVM build system has been taught to catch some common configuration
problems that <a href="http://llvm.cs.uiuc.edu/PR96">caused it to get
horribly confused</a>.</li>
<!--=========================================================================-->
<div class="doc_subsubsection">
<a name="codequality">In this release, the following Code Quality issues were fixed:</a>
</div>
<li>The LLVM header files are now
<a href="http://llvm.cs.uiuc.edu/PR114">-Wold-style-cast clean</a>.</li>
<ol>
<li><a href="http://llvm.cs.uiuc.edu/PR187">[loopsimplify] Many pointless phi nodes are created</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR237">[x86] wierd stack/frame pointer manipulation</a></li>
<li>The LLVM bytecode reader has been <a
href="http://llvm.cs.uiuc.edu/PR127">sped up a lot</a> (up to 4x in some
cases).</li>
<li>The X86 backend now generate <tt>fchs</tt> to negate floating point numbers,
compiles memcpy() into the <tt>rep movs</tt> instruction, and makes much better
use of powerful addressing modes and instructions.</li>
<li>In C++, methods and functions in anonymous namespaces <a href="http://llvm.cs.uiuc.edu/PR85">now get internal linkage</a>.</li>
<li>Constant initializers now generate loops instead of potentially <a href="http://llvm.cs.uiuc.edu/PR75">huge amounts of straight-line code</a>.</li>
<li>Code for running C++ destructors is now properly shared when possible. Before, the C++ front-end
<a href="http://llvm.cs.uiuc.edu/PR11">generated N^2 amounts of duplicated cleanup code</a> in some cases.</li>
<li>The JIT used to <a href="http://llvm.cs.uiuc.edu/PR177">generate code for
all functions pointed to by globals</a> before the program
started execution. Now, it waits until the first time the functions are
called to
compile them. This dramatically speeds up short runs of large C++ programs,
which often have large numbers of functions pointed to by vtables.</li>
</ol>
<!--=========================================================================-->
<div class="doc_subsubsection">
<a name="bugfix">In this release, the following bugs in the previous release were fixed:</a>
In this release, the following bugs in the previous release were fixed:
</div>
<p>Bugs in the LLVM Core:</p>
<ol>
<li><a href="http://llvm.cs.uiuc.edu/PR179">[licm] LICM promotes volatile memory
locations to registers</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR191">[licm] Memory read after free causes
infrequent crash</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR194">[indvars] Induction variable
canonicalization always makes 32-bit indvars</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR193">[constantmerge] Merging globals can
cause use of invalid pointers!</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR212">[bcreader] Bytecode reader misreads 'long -9223372036854775808'!</a></li>
<li><a href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=174">Tail duplication does not update SSA form correctly.</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR218">VMCore mishandles double -0.0</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR219">[X86] X86 backend code generates -0.0 as +0.0</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR223">[loopsimplify] Loopsimplify incorrectly updates dominator information</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR225">[pruneeh] -pruneeh pass removes invoke instructions it shouldn't</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR228">[sparc] Boolean constants are emitted as true and false</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR234">[interpreter] va_list values silently corrupted by function calls</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR235">Tablegen aborts on errors</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR236">[inliner] Error inlining intrinsic calls into invoke instructions</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR245">Linking weak and strong global variables is dependent on link order</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR258">Variables used to define non-printable FP constants are externally visible</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR259">CBE gives linkonce functions wrong linkage semantics</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR274">[JIT] Programs cannot resolve the fstat function</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR284">[indvars] Induction variable analysis violates LLVM invariants</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR296">[execution engines] Unhandled cast constant expression</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR299">[Sparc] Code generator asserts on alloca of zero size type</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR57">[inliner] Inlining invoke with PHI in unwind target is broken</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR58">[linker] linkonce globals should link successfully to external globals</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR64">[constmerge] Constant merging pass merges constants with external linkage</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR66">[scalarrepl] Scalar Replacement of aggregates is decimating structures it shouldn't be</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR70">[instcombine] Resolving invoke inserts cast after terminator</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR71">llvm-as crashes when labels are used in phi nodes</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR72">[build problem] Callgraph.cpp not pulled in from libipa.a</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR77">Variables in scope of output setjmp
calls should be volatile</a> (Note that this does not affect correctness on
many platforms, such as X86).</li>
<li><a href="http://llvm.cs.uiuc.edu/PR83">[X86] Emission of global bool initializers broken</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR91">[gccld] The -r (relinking) option does not work correctly</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR92">[bcreader] Cannot read shift constant expressions from bytecode file</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR93">[lowersetjmp] Lowersetjmp pass breaks dominance properties!</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR95">SymbolTable::getUniqueName is very inefficient</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR97">bugpoint must not pass -R&lt;directory&gt; to Mach-O linker</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR98">[buildscripts] Building into objdir with .o in it fails</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR101">[setjmp/longjmp] Linking C programs which use setjmp/longjmp sometimes fail with references to the C++ runtime library!</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR107">AsmParser Misses Symbol Redefinition Error</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR108">gccld -Lfoo -lfoo fails to find ./foo/libfoo.a</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR110">[bcreader] Incorrect cast causes misread forward constant references</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR116">[adce] ADCE considers blocks without postdominators to be unreachable</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR123">[X86] div and rem constant exprs invalidate iterators!</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR130">[vmcore] Symbol table doesn't rename colliding variables during type resolution</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR138">Archive reader does not understand 4.4BSD/Mac OS X long filenames</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR30">[llvm-ar] Command line arguments have funny syntax</a></li>
</ol>
<p>Bugs in the C/C++ front-end:</p>
<ol>
<li><a href="http://llvm.cs.uiuc.edu/PR186">Need weak linkage on memory
management functions in libc runtime to allow them to be overriden</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR202">[llvm-gcc] asserts when an extern inline function is redefined</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR204">[llvmg++] Dynamically initialized constants cannot be marked 'constant'</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR216">[llvmgcc] floating-point unary minus is incorrect for +0.0</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR221">[llvm-gcc] miscompilation of 'X = Y = Z' with aggregate values</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR272">[llvmgcc] Invalid code created for complex division operation</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR268">[llvmgcc] Incorrect code generation for pointer subtraction</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR261">[llvmg++] Crash assigning pointers-to-members with casted types</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR291">[llvm-g++] Cleanups and gotos don't mix properly</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR297">[llvmgcc] Crash on auto register variable with specific register specified</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR59">C++ frontend can crash when compiling virtual base classes</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR62">C backend fails on constant cast expr to ptr-to-anonymous struct</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR63">#ident is not recognized by C frontend</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR65">C front-end miscompiles the builtin_expect intrinsic!</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR67">1.0 precompiled libstdc++ does not include wchar_t support</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR68">llvmgcc asserts when compiling functions renamed with asm's</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR69">C frontend crashes on some programs with lots of types.</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR79">llvm-gcc crashes compiling global union initializer</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR80">C front-end crash on empty structure</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR81">CFrontend crashes when compiling C99 compound expressions</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR87">llvm-gcc infinite loops on "case MAXINT:"</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR89">[C++] Catch blocks make unparsable labels</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR90">[C++] Initializing array with constructible objects fail</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR94">llvm-gcc tries to add bools</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR104">[c++] C++ Frontend lays out superclasses like anonymous bitfields!</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR54">C front-end miscompiles unsigned enums whose LLVM types are signed</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR112">Casting a string constant to void crashes llvm-gcc</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR125">[llvmg++] Enum types are incorrectly shrunk to smaller than 'int' size</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR128">[llvmg++] Cannot use pointer to member to initialize global</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR131">[llvm-gcc] ?: operator as lvalue not implemented</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR133">[C/C++] Bogus warning about taking the address of 'register' variable</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR113">crash assigning into an array in a struct which contains a bitfield</a>.</li>
<li><a href="http://llvm.cs.uiuc.edu/PR6">Oversized integer bitfields cause crash</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR141">[llvm-gcc] Bitfields &amp; large array don't mix well</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR132">[llvm-gcc] Complex division is not supported</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR143">[llvm-gcc] Illegal union field reference</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR148">[llvmg++] Front-end attempts to return structure by value</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR152">[llvmg++] Pointer to member initializers not supported in constructors</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR155">[llvm-gcc] crash on union initialization</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR124">[llvm-g++] ?: expressions do not run correct number of destructors!</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR157">[llvm-gcc] Pointer & constant results in invalid shift</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR165">[llvmg++] call through array of pointers to member functions causes assertion</a></li>
</ol>
</div>
@@ -263,7 +305,7 @@ management functions in libc runtime to allow them to be overriden</a></li>
<div class="doc_text">
<p>LLVM has been extensively tested on Intel and AMD machines running Red
Hat Linux and FreeBSD. It has also been tested on Sun UltraSPARC workstations running Solaris 8.
Hat Linux and has been tested on Sun UltraSPARC workstations running Solaris 8.
Additionally,
LLVM works on Mac OS X 10.3 and above, but only with the C backend or
interpreter (no native backend for the PowerPC is available yet).
@@ -290,32 +332,11 @@ there isn't already one.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="experimental">Experimental features included with this release</a>
</div>
<!-- _______________________________________________________________________ -->
<!--
</ul><h4><a name="portability"><hr size=0>Portability Problems</h4><ul>
-->
<div class="doc_text">
<p>
The following components of this LLVM release are either untested, known to be
broken or unreliable, or are in early development. These components should not
be relied on, and bugs should not be filed against them, but they may be useful
to some people. In particular, if you would like to work on one of these
components, please contact us on the llvmdev list.
</p>
<ul>
<li>The following passes are incomplete or buggy: <tt>-pgmdep, -memdep,
-ipmodref, -sortstructs, -swapstructs, -cee</tt></li>
<li>The <tt>-pre</tt> pass is incomplete (there are cases it doesn't handle that
it should) and not thoroughly tested.</li>
<li>The <tt>llvm-ar</tt> tool is incomplete and probably buggy.</li>
<li>The <tt>llvm-db</tt> tool is in a very early stage of development.</li>
</ul>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
@@ -341,13 +362,20 @@ table in the archive).</li>
<li><a href="http://llvm.cs.uiuc.edu/PR82">LLVM cannot handle structures with
more than 256 elements</a>.</li>
<li>The gccld program <a href="http://llvm.cs.uiuc.edu/PR139">does not link objects/archives in the order specified on the command line.</a></li>
<li>
The gccld program
<a href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=139">
does not link objects/archives in the order specified on the command line.
</a>
</li>
<li><a href="http://llvm.cs.uiuc.edu/PR240">The lower-invoke pass does not mark
values live across a setjmp as volatile</a>. This missing feature only affects
targets whose setjmp/longjmp libraries do not save and restore the entire
register file.</li>
<li>
<a href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=174">
Tail duplication does not update SSA form correctly.
</a>
</li>
</ul>
</div>
<!-- ======================================================================= -->
@@ -356,7 +384,9 @@ register file.</li>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">Bugs</div>
<div class="doc_subsubsection">
Bugs
</div>
<div class="doc_text">
<ul>
@@ -375,8 +405,20 @@ Initialization of global union variables can only be done
union member</a>.
</li>
<li><a href="http://llvm.cs.uiuc.edu/PR244">[llvm-gcc] Error when an implicitly external function is re-declared as static</a></li>
<li>
<a href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=182">
Functions marked "extern inline" are not compiled into LLVM with linkonce
linkage.
</a>
</li>
<li>
The memory management functions in the libc runtime
<a href="http://llvm.cs.uiuc.edu/PR186">need weak linkage so that they can be
overridden.
</a>
</li>
</ul>
</div>
@@ -409,12 +451,14 @@ work:
the following extensions are known to <b>not be</b> supported:
<ol>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Local-Labels.html#Local%20Labels">Local Labels</a>: Labels local to a block.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html#Labels%20as%20Values">Labels as Values</a>: Getting pointers to labels and computed gotos.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html#Nested%20Functions">Nested Functions</a>: As in Algol and Pascal, lexical scoping of functions.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Constructing-Calls.html#Constructing%20Calls">Constructing Calls</a>: Dispatching a call to another function.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended%20Asm">Extended Asm</a>: Assembler instructions with C expressions as operands.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Constraints.html#Constraints">Constraints</a>: Constraints for asm operands.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Asm-Labels.html#Asm%20Labels">Asm Labels</a>: Specifying the assembler name to use for a C symbol.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Explicit-Reg-Vars.html#Explicit%20Reg%20Vars">Explicit Reg Vars</a>: Defining variables residing in specified registers.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Return-Address.html#Return%20Address">Return Address</a>: Getting the return or frame address of a function.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html#Vector%20Extensions">Vector Extensions</a>: Using vector instructions through built-in functions.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Target-Builtins.html#Target%20Builtins">Target Builtins</a>: Built-in functions specific to particular targets.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html#Thread-Local">Thread-Local</a>: Per-thread variables.</li>
@@ -479,7 +523,6 @@ work:
<p>The following extensions <b>are</b> known to be supported:</p>
<ol>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html#Labels%20as%20Values">Labels as Values</a>: Getting pointers to labels and computed gotos.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html#Statement%20Exprs">Statement Exprs</a>: Putting statements and declarations inside expressions.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Typeof.html#Typeof">Typeof</a>: <code>typeof</code>: referring to the type of an expression.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Lvalues.html#Lvalues">Lvalues</a>: Using <code>?:</code>, "<code>,</code>" and casts in lvalues.</li>
@@ -509,7 +552,6 @@ or arrays as values.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Alternate-Keywords.html#Alternate%20Keywords">Alternate Keywords</a>:<code>__const__</code>, <code>__asm__</code>, etc., for header files.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Incomplete-Enums.html#Incomplete%20Enums">Incomplete Enums</a>: <code>enum foo;</code>, with details to follow.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Function-Names.html#Function%20Names">Function Names</a>: Printable strings which are the name of the current function.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Return-Address.html#Return%20Address">Return Address</a>: Getting the return or frame address of a function.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html#Unnamed%20Fields">Unnamed Fields</a>: Unnamed struct/union fields within structs/unions.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute%20Syntax">Attribute Syntax</a>: Formal syntax for attributes.</li>
</ol></li>
@@ -536,13 +578,21 @@ Please report any bugs or problems.</p>
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">Bugs</div>
<div class="doc_subsubsection">
Bugs
</div>
<div class="doc_text">
<ul>
<li>The C++ front-end inherits all problems afflicting the <a href="#c-fe">C
front-end</a>.</li>
<li>
<a href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=137">
Code is generated for empty classes.
</a>
</li>
</ul>
</div>
@@ -589,7 +639,12 @@ href="http://gcc.gnu.org/gcc-3.4/changes.html">GCC 3.4 release notes</a>.</li>
<div class="doc_text">
<ul>
<li>None so far.
<li>The X86 code generator <a
href="http://llvm.cs.uiuc.edu/PR16">does not currently
support the <tt>unwind</tt> instruction</a>, so code that throws a C++ exception
or calls the C <tt>longjmp</tt> function will abort.</li>
</ul>
</div>
@@ -602,7 +657,17 @@ href="http://gcc.gnu.org/gcc-3.4/changes.html">GCC 3.4 release notes</a>.</li>
<div class="doc_text">
<ul>
<li>There are several programs in the LLVM testsuite that the Sparc code generator is known to miscompile.</li>
<li>The Sparc code generator <a
href="http://llvm.cs.uiuc.edu/PR15">does not currently
support the <tt>unwind</tt> instruction</a>, so code that throws a C++ exception
or calls the C <tt>longjmp</tt> function will abort.</li>
<li>
<a href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=167">
The llc program can crash on legal code.
</a>
</li>
</ul>
</div>
@@ -658,7 +723,7 @@ lists</a>.</p>
<hr>
<address>
<a href="http://jigsaw.w3.org/css-validator/check/referer"><img
<a href="http://jigsaw.w3.org/css-validator/"><img
src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
<a href="http://validator.w3.org/check/referer"><img
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>

File diff suppressed because it is too large Load Diff

File diff suppressed because it is too large Load Diff

View File

@@ -1,653 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>TableGen Fundamentals</title>
<link rel="stylesheet" href="llvm.css" type="text/css">
</head>
<body>
<div class="doc_title">TableGen Fundamentals</div>
<ul>
<li><a href="#introduction">Introduction</a></li>
<ol>
<li><a href="#concepts">Basic concepts</a></li>
<li><a href="#example">An example record</a></li>
<li><a href="#running">Running TableGen</a></li>
</ol>
<li><a href="#syntax">TableGen syntax</a></li>
<ol>
<li><a href="#primitives">TableGen primitives</a></li>
<ol>
<li><a href="#comments">TableGen comments</a></li>
<li><a href="#types">The TableGen type system</a></li>
<li><a href="#values">TableGen values and expressions</a></li>
</ol>
<li><a href="#classesdefs">Classes and definitions</a></li>
<ol>
<li><a href="#valuedef">Value definitions</a></li>
<li><a href="#recordlet">'let' expressions</a></li>
<li><a href="#templateargs">Class template arguments</a></li>
</ol>
<li><a href="#filescope">File scope entities</a></li>
<ol>
<li><a href="#include">File inclusion</a></li>
<li><a href="#globallet">'let' expressions</a></li>
</ol>
</ol>
<li><a href="#backends">TableGen backends</a></li>
<ol>
<li><a href="#">todo</a></li>
</ol>
<li><a href="#codegenerator">The LLVM code generator</a></li>
<ol>
<li><a href="#">todo</a></li>
</ol>
</ul>
<!-- *********************************************************************** -->
<div class="doc_section"><a name="introduction">Introduction</a></div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>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.</p>
<p>The core part of TableGen <a href="#syntax">parses a file</a>, instantiates
the declarations, and hands the result off to a domain-specific "<a
href="#backends">TableGen backend</a>" for processing. The current major user
of TableGen is the <a href="#codegenerator">LLVM code generator</a>.
</p>
<p>
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 <tt>llvm/utils/emacs</tt>
and <tt>llvm/utils/vim</tt> directory of your LLVM distribution, respectively.
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="running">Basic concepts</a>
</div>
<div class="doc_text">
<p>
TableGen files consist of two key parts: 'classes' and 'definitions', both of
which are considered 'records'.
</p>
<p>
<b>TableGen records</b> have a unique name, a list of values, and a list of
superclasses. The list of values is 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 <a
href="#backends">TableGen backend</a>, but the structure and format rules are
taken care of and fixed by TableGen.
</p>
<p>
<b>TableGen definitions</b> are the concrete form of 'records'. These generally
do not have any undefined values, and are marked with the '<tt>def</tt>'
keyword.
</p>
<p>
<b>TableGen classes</b> 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 targetting (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".
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="example">An example record</a>
</div>
<div class="doc_text">
<p>
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 <tt>X86.td</tt> file
prints this (at the time of this writing):
</p>
<p>
<pre>
...
<b>def</b> ADDrr8 { <i>// Instruction X86Inst I2A8 Pattern</i>
<b>string</b> Name = "add";
<b>string</b> Namespace = "X86";
<b>list</b>&lt;Register&gt; Uses = [];
<b>list</b>&lt;Register&gt; Defs = [];
<b>bit</b> isReturn = 0;
<b>bit</b> isBranch = 0;
<b>bit</b> isCall = 0;
<b>bit</b> isTwoAddress = 1;
<b>bit</b> isTerminator = 0;
<b>dag</b> Pattern = (set R8, (plus R8, R8));
<b>bits</b>&lt;8&gt; Opcode = { 0, 0, 0, 0, 0, 0, 0, 0 };
Format Form = MRMDestReg;
<b>bits</b>&lt;5&gt; FormBits = { 0, 0, 0, 1, 1 };
ArgType Type = Arg8;
<b>bits</b>&lt;3&gt; TypeBits = { 0, 0, 1 };
<b>bit</b> hasOpSizePrefix = 0;
<b>bit</b> printImplicitUses = 0;
<b>bits</b>&lt;4&gt; Prefix = { 0, 0, 0, 0 };
FPFormat FPForm = ?;
<b>bits</b>&lt;3&gt; FPFormBits = { 0, 0, 0 };
}
...
</pre><p>
<p>
This definition corresponds to an 8-bit register-register add instruction in the
X86. The string after the '<tt>def</tt>' string indicates the name of the
record ("<tt>ADDrr8</tt>" in this case), 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, should be printed as "<tt>add</tt>"
in the assembly file, it is a two-address instruction, has a particular
encoding, etc. The contents and semantics of the information in the record is
specific to the needs of the X86 backend, and is only shown as an example.
</p>
<p>
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 unmaintainble,
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:
</p>
<p><pre>
<b>def</b> ADDrr8 : I2A8&lt;"add", 0x00, MRMDestReg&gt;,
Pattern&lt;(set R8, (plus R8, R8))&gt;;
</pre></p>
<p>
This definition makes use of the custom I2A8 (two address instruction with 8-bit
operand) class, 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.
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="running">Running TableGen</a>
</div>
<div class="doc_text">
<p>
TableGen runs just like any other LLVM tool. The first (optional) argument
specifies the file to read. If a filename is not specified, <tt>tblgen</tt>
reads from standard input.
</p>
<p>
To be useful, one of the <a href="#backends">TableGen backends</a> must be used.
These backends are selectable on the command line (type '<tt>tblgen --help</tt>'
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 <tt>--print-enums</tt> option:
</p>
<p><pre>
$ tblgen X86.td -print-enums -class=Register
AH, AL, AX, BH, BL, BP, BX, CH, CL, CX, DH, DI, DL, DX,
EAX, EBP, EBX, ECX, EDI, EDX, ESI, ESP, FP0, FP1, FP2, FP3, FP4, FP5, FP6,
SI, SP, ST0, ST1, ST2, ST3, ST4, ST5, ST6, ST7,
$ tblgen X86.td -print-enums -class=Instruction
ADCrr32, ADDri16, ADDri16b, ADDri32, ADDri32b, ADDri8, ADDrr16, ADDrr32,
ADDrr8, ADJCALLSTACKDOWN, ADJCALLSTACKUP, ANDri16, ANDri16b, ANDri32, ANDri32b,
ANDri8, ANDrr16, ANDrr32, ANDrr8, BSWAPr32, CALLm32, CALLpcrel32, ...
</pre></p>
<p>
The default backend prints out all of the records, as described <a
href="#example">above</a>.
</p>
<p>
If you plan to use TableGen for some purpose, you will most likely have to <a
href="#backends">write a backend</a> that extracts the information specific to
what you need and formats it in the appropriate way.
</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section"><a name="syntax">TableGen syntax</a></div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>
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.
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="primitives">TableGen primitives</tt></a>
</div>
<!----------------------------------------------------------------------------->
<div class="doc_subsubsection">
<a name="comments">TableGen comments</tt></a>
</div>
<div class="doc_text">
<p>TableGen supports BCPL style "<tt>//</tt>" comments, which run to the end of
the line, and it also supports <b>nestable</b> "<tt>/* */</tt>" comments.</p>
</div>
<!----------------------------------------------------------------------------->
<div class="doc_subsubsection">
<a name="types">The TableGen type system</tt></a>
</div>
<div class="doc_text">
<p>
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 <a
href="#valuedef">value definition</a> is required to have an associated type.
</p>
<p>
TableGen supports a mixture of very low-level types (such as <tt>bit</tt>) and
very high-level types (such as <tt>dag</tt>). This flexibility is what allows
it to describe a wide range of information conveniently and compactly. The
TableGen types are:
</p>
<p>
<ul>
<li>"<tt><b>bit</b></tt>" - A 'bit' is a boolean value that can hold either 0 or
1.</li>
<li>"<tt><b>int</b></tt>" - The 'int' type represents a simple 32-bit integer
value, such as 5.</li>
<li>"<tt><b>string</b></tt>" - The 'string' type represents an ordered sequence
of characters of arbitrary length.</li>
<li>"<tt><b>bits</b>&lt;n&gt;</tt>" - 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.</li>
<li>"<tt><b>list</b>&lt;ty&gt;</tt>" - This type represents a list whose
elements are some other type. The contained type is arbitrary: it can even be
another list type.</li>
<li>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 <tt><b>list</b>&lt;Register&gt;</tt> can
only contain definitions derived from the "<tt>Register</tt>" class).</li>
<li>"<tt><b>code</b></tt>" - This represents a big hunk of text. NOTE: I don't
remember why this is distinct from string!</li>
<li>"<tt><b>dag</b></tt>" - This type represents a nestable directed graph of
elements.</li>
</ul>
</p>
<p>
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.
</p>
</div>
<!----------------------------------------------------------------------------->
<div class="doc_subsubsection">
<a name="values">TableGen values and expressions</tt></a>
</div>
<div>
<p>
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:
</p>
<p><ul>
<li>? - Uninitialized field.</li>
<li>0b1001011 - Binary integer value.</li>
<li>07654321 - Octal integer value (indicated by a leading 0).</li>
<li>7 - Decimal integer value.</li>
<li>0x7F - Hexadecimal integer value.</li>
<li>"foo" - String value.</li>
<li>[{ .... }] - Code fragment.</li>
<li>[ X, Y, Z ] - List value.</li>
<li>{ a, b, c } - Initializer for a "bits&lt;3&gt;" value.</li>
<li>value - Value reference.</li>
<li>value{17} - Access to one or more bits of a value.</li>
<li>DEF - Reference to a record definition.</li>
<li>X.Y - Reference to the subfield of a value.</li>
<li>(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.</li>
</ul></p>
<p>
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&lt;4&gt;" value, for example.
</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="classesdefs">Classes and definitions</tt></a>
</div>
<div>
<p>
As mentioned in the <a href="#concepts">intro</a>, 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 <tt>def</tt> or
<tt>class</tt> keyword, the record name, and an optional list of "<a
href="templateargs">template arguments</a>". If the record has superclasses,
they are specified as a comma seperated list that starts with a colon character
(":"). If <a href="#valuedef">value definitions</a> or <a href="#recordlet">let
expressions</a> are needed for the class, they are enclosed in curly braces
("{}"); otherwise, the record ends with a semicolon. Here is a simple TableGen
file:
</p>
<p><pre>
<b>class</b> C { <b>bit</b> V = 1; }
<b>def</b> X : C;
<b>def</b> Y : C {
<b>string</b> Greeting = "hello";
}
</pre></p>
<p>
This example defines two definitions, <tt>X</tt> and <tt>Y</tt>, both of which
derive from the <tt>C</tt> class. Because of this, they both get the <tt>V</tt>
bit value. The <tt>Y</tt> definition also gets the Greeting member as well.
</p>
<p>
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.
</p>
</div>
<!----------------------------------------------------------------------------->
<div class="doc_subsubsection">
<a name="valuedef">Value definitions</tt></a>
</div>
<div class="doc_text">
<p>
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 <a href="#recordlet">let expression</a>. A
value is defined by specifying a <a href="#types">TableGen type</a> 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.
</div>
<!----------------------------------------------------------------------------->
<div class="doc_subsubsection">
<a name="recordlet">'let' expressions</tt></a>
</div>
<div class="doc_text">
<p>
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
'<tt>let</tt>' 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 <tt>V</tt> field for all of its subclasses:</p>
<p><pre>
<b>class</b> D : C { let V = 0; }
<b>def</b> Z : D;
</pre></p>
<p>
In this case, the <tt>Z</tt> definition will have a zero value for its "V"
value, despite the fact that it derives (indirectly) from the <tt>C</tt> class,
because the <tt>D</tt> class overrode its value.
</p>
</div>
<!----------------------------------------------------------------------------->
<div class="doc_subsubsection">
<a name="templateargs">Class template arguments</tt></a>
</div>
<div class="doc_text">
<p>
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:</p>
<p><pre>
<b>class</b> FPFormat&lt;<b>bits</b>&lt;3&gt; val&gt; {
<b>bits</b>&lt;3&gt; Value = val;
}
<b>def</b> NotFP : FPFormat&lt;0&gt;;
<b>def</b> ZeroArgFP : FPFormat&lt;1&gt;;
<b>def</b> OneArgFP : FPFormat&lt;2&gt;;
<b>def</b> OneArgFPRW : FPFormat&lt;3&gt;;
<b>def</b> TwoArgFP : FPFormat&lt;4&gt;;
<b>def</b> SpecialFP : FPFormat&lt;5&gt;;
</pre></p>
<p>
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.</p>
<p>The more esoteric forms of <a href="#values">TableGen expressions</a> are
useful in conjunction with template arguments. As an example:</p>
<p><pre>
<b>class</b> ModRefVal&lt;<b>bits</b>&lt;2&gt; val&gt; {
<b>bits</b>&lt;2&gt; Value = val;
}
<b>def</b> None : ModRefVal&lt;0&gt;;
<b>def</b> Mod : ModRefVal&lt;1&gt;;
<b>def</b> Ref : ModRefVal&lt;2&gt;;
<b>def</b> ModRef : ModRefVal&lt;3&gt;;
<b>class</b> Value&lt;ModRefVal MR&gt; {
<i>// decode some information into a more convenient format, while providing
// a nice interface to the user of the "Value" class.</i>
<b>bit</b> isMod = MR.Value{0};
<b>bit</b> isRef = MR.Value{1};
<i>// other stuff...</i>
}
<i>// Example uses</i>
<b>def</b> bork : Value&lt;Mod&gt;;
<b>def</b> zork : Value&lt;Ref&gt;;
<b>def</b> hork : Value&lt;ModRef&gt;;
</pre></p>
<p>
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 <tt>tblgen</tt> on the example prints the following definitions:</p>
<p><pre>
<b>def</b> bork { <i>// Value</i>
bit isMod = 1;
bit isRef = 0;
}
<b>def</b> hork { <i>// Value</i>
bit isMod = 1;
bit isRef = 1;
}
<b>def</b> zork { <i>// Value</i>
bit isMod = 0;
bit isRef = 1;
}
</pre></p>
<p>
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.</p>
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="filescope">File scope entities</tt></a>
</div>
<!----------------------------------------------------------------------------->
<div class="doc_subsubsection">
<a name="include">File inclusion</tt></a>
</div>
<div class="doc_text">
<p>
TableGen supports the '<tt>include</tt>' 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 '<tt>include</tt>'
keyword. Example:
<p><pre>
<b>include</b> "foo.td"
</pre></p>
</div>
<!----------------------------------------------------------------------------->
<div class="doc_subsubsection">
<a name="globallet">'let' expressions</tt></a>
</div>
<div class="doc_text">
<p>
"let" expressions at file scope are similar to <a href="#recordlet">"let"
expressions within a record</a>, 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.
</p>
<p>
File-scope "let" expressions take a comma-seperated list of bindings to apply,
and one of more records to bind the values in. Here are some examples:
</p>
<p><pre>
<b>let</b> isTerminator = 1, isReturn = 1 <b>in</b>
<b>def</b> RET : X86Inst&lt;"ret", 0xC3, RawFrm, NoArg&gt;;
<b>let</b> isCall = 1 <b>in</b>
<i>// All calls clobber the non-callee saved registers...</i>
<b>let</b> Defs = [EAX, ECX, EDX, FP0, FP1, FP2, FP3, FP4, FP5, FP6] in {
<b>def</b> CALLpcrel32 : X86Inst&lt;"call", 0xE8, RawFrm, NoArg&gt;;
<b>def</b> CALLr32 : X86Inst&lt;"call", 0xFF, MRMS2r, Arg32&gt;;
<b>def</b> CALLm32 : X86Inst&lt;"call", 0xFF, MRMS2m, Arg32&gt;;
}
</pre></p>
<p>
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.
</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section"><a name="backends">TableGen backends</a></div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>
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.
</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section"><a name="codegenerator">The LLVM code generator</a></div>
<!-- *********************************************************************** -->
<div class="doc_text">
<p>
This is just a temporary, convenient, place to put stuff about the code
generator before it gets its own document. This should describe all of the
tablegen backends used by the code generator and the classes/definitions they
expect.
</p>
</div>
<!-- *********************************************************************** -->
<hr>
<div class="doc_footer">
<address><a href="mailto:sabre@nondot.org">Chris Lattner</a></address>
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
<br>
Last modified: $Date$
</div>
</body>
</html>

View File

@@ -1,10 +1,11 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>LLVM Test Suite Guide</title>
<link rel="stylesheet" href="llvm.css" type="text/css">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<link rel="stylesheet" href="llvm.css" type="text/css" media="screen" />
<title>LLVM Test Suite Guide</title>
</head>
<body>
<div class="doc_title">
@@ -15,369 +16,414 @@
<li><a href="#overview">Overview</a></li>
<li><a href="#Requirements">Requirements</a></li>
<li><a href="#quick">Quick Start</a></li>
<li><a href="#org">LLVM Test Suite Organization</a>
<li><a href="#org">LLVM Test Suite Organization</a></li>
<ul>
<li><a href="#codefragments">Code Fragments</a></li>
<li><a href="#wholeprograms">Whole Programs</a></li>
</ul></li>
</ul>
<li><a href="#tree">LLVM Test Suite Tree</a></li>
<li><a href="#qmstructure">QMTest Structure</a></li>
<li><a href="#progstructure">Programs Structure</a></li>
<li><a href="#run">Running the LLVM Tests</a></li>
<p><b>Written by John T. Criswell</b></p>
</ol>
<p><b>Written by John T. Criswell</b></p>
<!--===============================================================-->
<div class="doc_section"><a name="overview">Overview</a></div>
<!--===============================================================-->
<!--===============================================================-->
<div class="doc_section"><a name="overview">Overview</a></div>
<!--===============================================================-->
<div class="doc_text">
<p>
This document is the reference manual for the LLVM test suite. It
documents the structure of the LLVM test suite, the tools needed to
use it, and how to add and run tests.
</p>
</div>
<div class="doc_text">
<!--===============================================================-->
<div class="doc_section"><a name="Requirements">Requirements</a></div>
<!--===============================================================-->
<p>This document is the reference manual for the LLVM test suite. It documents
the structure of the LLVM test suite, the tools needed to use it, and how to add
and run tests.</p>
<div class="doc_text">
<p>
In order to use the LLVM test suite, you will need all of the software
required to build LLVM, plus the following:
</p>
<dl compact>
<dt><A HREF="http://www.qmtest.com">QMTest</A></dt>
<dd>The LLVM test suite uses QMTest to organize and
run tests.</dd>
</div>
<dt><A HREF="http://www.python.org">Python</A></dt>
<dd>You will need a Python interpreter that works with
QMTest. Python will need zlib and SAX support
enabled.</dd>
</dl>
</div>
<!--===============================================================-->
<div class="doc_section"><a name="Requirements">Requirements</a></div>
<!--===============================================================-->
<!--===============================================================-->
<div class="doc_section"><a name="quick">Quick Start</a></div>
<!--===============================================================-->
<div class="doc_text">
<div class="doc_text">
<p>
The tests are located in the LLVM source tree under the directory
<tt>llvm/test</tt>. To run all of the tests in LLVM, use the Master
Makefile in that directory:
</p>
<pre>
% gmake -C llvm/test
</pre>
<p>In order to use the LLVM test suite, you will need all of the software
required to build LLVM, plus the following:</p>
<p>
To run only the code fragment tests (i.e. those that do basic testing of
LLVM), run the tests organized by QMTest:
</p>
<dl>
<dt><a href="http://www.qmtest.com">QMTest</A></dt>
<dd>The LLVM test suite uses QMTest to organize and run tests.</dd>
<pre>
% gmake -C llvm/test qmtest
</pre>
<dt><a href="http://www.python.org">Python</A></dt>
<dd>You will need a Python interpreter that works with QMTest. Python will
need zlib and SAX support enabled.</dd>
</dl>
<p>
To run only the tests that compile and execute whole programs, run the
Programs tests:
</p>
</div>
<pre>
% gmake -C llvm/test/Programs
</pre>
</div>
<!--===============================================================-->
<div class="doc_section"><a name="quick">Quick Start</a></div>
<!--===============================================================-->
<!--===============================================================-->
<div class="doc_section"><h2><a name="org">LLVM Test Suite
Organization </a></h2></div>
<!--===============================================================-->
<div class="doc_text">
<div class="doc_text">
<p>The LLVM test suite contains two major categories of tests: code
fragments and whole programs.</p>
</div>
<p> The tests are located in the LLVM source tree under the directory
<tt>llvm/test</tt>. To run all of the tests in LLVM, use the Master Makefile in
that directory:</p>
<div class="doc_subsection"><a name="codefragments">Code Fragments</a>
</div>
<pre>
% gmake -C llvm/test
</pre>
<div class="doc_text">
<p>
Code fragments are small pieces of code that test a specific
feature of LLVM or trigger a specific bug in LLVM. They are
usually written in LLVM assembly language, but can be
written in other languages if the test targets a
particular language front end.
</p><p>
Code fragments are not complete programs, and they are
never executed to determine correct behavior.
</p><p>
The tests in the Features and
Regression directories contain code fragments.
</p>
</div>
<p>To run only the code fragment tests (i.e. those that do basic testing of
LLVM), run the tests organized by QMTest:</p>
<div class="doc_subsection"><a name="wholeprograms">Whole Programs</a>
</div>
<pre>
% gmake -C llvm/test qmtest
</pre>
<div class="doc_text">
<p>
Whole Programs are pieces of code which can be compiled and
linked into a stand-alone program that can be executed. These
programs are generally written in high level languages such as C
or C++, but sometimes they are written straight in LLVM
assembly.
</p><p>
These programs are compiled and then executed using several
different methods (native compiler, LLVM C backend, LLVM JIT,
LLVM native code generation, etc). The output of these programs
is compared to ensure that LLVM is compiling the program
correctly.
</p><p>
In addition to compiling and executing programs, whole program
tests serve as a way of benchmarking LLVM performance, both in
terms of the efficiency of the programs generated as well as the
speed with which LLVM compiles, optimizes, and generates code.
</p><p>
The Programs directory contains all tests which compile and
benchmark whole programs.
</p>
</div>
<p>To run only the tests that compile and execute whole programs, run the
Programs tests:</p>
<!--===============================================================-->
<div class="doc_section"><h2><a name="tree">LLVM Test Suite Tree</a>
</div>
<!--===============================================================-->
<pre>
% gmake -C llvm/test/Programs
</pre>
</div>
<!--===============================================================-->
<div class="doc_section"><a name="org">LLVM Test Suite Organization</a></div>
<!--===============================================================-->
<div class="doc_text">
<p>The LLVM test suite contains two major categories of tests: code
fragments and whole programs.</p>
</div>
<div class="doc_subsection"><a name="codefragments">Code Fragments</a>
</div>
<div class="doc_text">
<p>Code fragments are small pieces of code that test a specific feature of LLVM
or trigger a specific bug in LLVM. They are usually written in LLVM assembly
language, but can be written in other languages if the test targets a particular
language front end.</p>
<p>Code fragments are not complete programs, and they are never executed to
determine correct behavior.</p>
<p>The tests in the Features and Regression directories contain code
fragments.</p>
</div>
<div class="doc_subsection"><a name="wholeprograms">Whole Programs</a></div>
<div class="doc_text">
<p>Whole Programs are pieces of code which can be compiled and linked into a
stand-alone program that can be executed. These programs are generally written
in high level languages such as C or C++, but sometimes they are written
straight in LLVM assembly.</p>
<p>These programs are compiled and then executed using several different
methods (native compiler, LLVM C backend, LLVM JIT, LLVM native code generation,
etc). The output of these programs is compared to ensure that LLVM is compiling
the program correctly.</p>
<p>In addition to compiling and executing programs, whole program tests serve as
a way of benchmarking LLVM performance, both in terms of the efficiency of the
programs generated as well as the speed with which LLVM compiles, optimizes, and
generates code.</p>
<p>The Programs directory contains all tests which compile and benchmark whole
programs.</p>
</div>
<!--===============================================================-->
<div class="doc_section"><a name="tree">LLVM Test Suite Tree</a></div>
<!--===============================================================-->
<div class="doc_text">
<p>Each type of test in the LLVM test suite has its own directory. The major
subtrees of the test suite directory tree are as follows:</p>
<ul>
<li>Features
<p>This directory contains sample codes that test various features of the
LLVM language. These pieces of sample code are run through various
assembler, disassembler, and optimizer passes.</p>
<li>Regression
<p>This directory contains regression tests for LLVM. When a bug is found
in LLVM, a regression test containing just enough code to reproduce the
problem should be written and placed somewhere underneath this directory.
In most cases, this will be a small piece of LLVM assembly language code,
often distilled from an actual application or benchmark.</p>
<li>Programs
<p>The Programs directory contains programs that can be compiled with LLVM
and executed. These programs are compiled using the native compiler and
various LLVM backends. The output from the program compiled with the native
compiler is assumed correct; the results from the other programs are
compared to the native program output and pass if they match. </p>
<p> In addition for testing correctness, the Programs directory also
performs timing tests of various LLVM optimizations. It also records
compilation times for the compilers and the JIT. This information can be
used to compare the effectiveness of LLVM's optimizations and code
generation.</p>
<p>The Programs directory is subdivided into several smaller subdirectories:
</p>
<ul>
<li>Programs/SingleSource
<p>The SingleSource directory contains test programs that are only a
single source file in size. These are usually small benchmark programs
or small programs that calculate a particular value. Several such
programs are grouped together in each directory.</p></li>
<li>Programs/MultiSource
<p>The MultiSource directory contains subdirectories which contain
entire programs with multiple source files. Large benchmarks and whole
applications go here.</p></li>
<li>Programs/External
<p>The External directory contains Makefiles for building code that is
external to (i.e. not distributed with) LLVM. The most prominent member
of this directory is the SPEC 2000 benchmark suite. The presence and
location of these external programs is configured by the LLVM
<tt>configure</tt> script.</p></li>
<div class="doc_text">
<p>Each type of test in the LLVM test suite has its own directory. The
major subtrees of the test suite directory tree are as follows:</p>
</ul></li>
<ul>
<li>Features
<p>
This directory contains sample codes that test various features
of the LLVM language. These pieces of sample code are run
through various assembler, disassembler, and optimizer passes.
</p>
<li>QMTest
<p>This directory contains the QMTest information files. Inside this
directory are QMTest administration files and the Python code that
implements the LLVM test and database classes.</p>
<li>Regression
<p>
This directory contains regression tests for LLVM. When a bug
is found in LLVM, a regression test containing just enough
code to reproduce the problem should be written and placed
somewhere underneath this directory. In most cases, this
will be a small piece of LLVM assembly language code, often
distilled from an actual application or benchmark.
</p>
</ul>
<li>Programs
<p>
The Programs directory contains programs that can be compiled
with LLVM and executed. These programs are compiled using the
native compiler and various LLVM backends. The output from the
program compiled with the native compiler is assumed correct;
the results from the other programs are compared to the native
program output and pass if they match.
</p><p>
In addition for testing correctness, the Programs directory
also performs timing tests of various LLVM optimizations.
It also records compilation times for the compilers and the
JIT. This information can be used to compare the
effectiveness of LLVM's optimizations and code generation.
</p><p>
The Programs directory is subdivided into several smaller
subdirectories:
</p>
</div>
<ul>
<li>Programs/SingleSource
<p>
The SingleSource directory contains test programs that
are only a single source file in size. These are
usually small benchmark programs or small programs that
calculate a particular value. Several such programs are
grouped together in each directory.
</p>
<!--===============================================================-->
<div class="doc_section"><a name="qmstructure">QMTest Structure</a></div>
<!--===============================================================-->
<li>Programs/MultiSource
<p>
The MultiSource directory contains subdirectories which
contain entire programs with multiple source files.
Large benchmarks and whole applications go here.
</p>
<div class="doc_text">
<li>Programs/External
<p>
The External directory contains Makefiles for building
code that is external to (i.e. not distributed with)
LLVM. The most prominent member of this directory is
the SPEC 2000 benchmark suite. The presence and
location of these external programs is configured by the
LLVM <tt>configure</tt> script.
</p>
</ul>
<p>The LLVM test suite is partially driven by QMTest and partially
driven by GNU Make. Specifically, the Features and Regression tests
are all driven by QMTest. The Programs directory is currently
driven by a set of Makefiles.</p>
<p>
<p>The QMTest system needs to have several pieces of information
available; these pieces of configuration information are known
collectively as the "context" in QMTest parlance. Since the context
for LLVM is relatively large, the master Makefile in llvm/test
sets it for you.</p>
<li>QMTest
<p>
This directory contains the QMTest information files. Inside
this directory are QMTest administration files and the Python
code that implements the LLVM test and database classes.
</p>
</ul>
</div>
<p>The LLVM database class makes the subdirectories of llvm/test a
QMTest test database. For each directory that contains tests driven by
QMTest, it knows what type of test the source file is and how to run it.</p>
<!--===============================================================-->
<div class="doc_section"><h2><a name="qmstructure">QMTest Structure</a>
</div>
<!--===============================================================-->
<p>Hence, the QMTest namespace is essentially what you see in the
Feature and Regression directories, but there is some magic that
the database class performs (as described below).</p>
<div class="doc_text">
<p>
The LLVM test suite is partially driven by QMTest and partially
driven by GNU Make. Specifically, the Features and Regression tests
are all driven by QMTest. The Programs directory is currently
driven by a set of Makefiles.
</p><p>
The QMTest system needs to have several pieces of information
available; these pieces of configuration information are known
collectively as the "context" in QMTest parlance. Since the context
for LLVM is relatively large, the master Makefile in llvm/test
sets it for you.
</p><p>
The LLVM database class makes the subdirectories of llvm/test a
QMTest test database. For each directory that contains tests driven by
QMTest, it knows what type of test the source file is and how to run it.
</p><p>
Hence, the QMTest namespace is essentially what you see in the
Feature and Regression directories, but there is some magic that
the database class performs (as described below).
</p><p>
The QMTest namespace is currently composed of the following tests and
test suites:
</p>
<p>The QMTest namespace is currently composed of the following tests and test
suites:</p>
<ul>
<li>Feature
<p>
These are the feature tests found in the Feature directory.
They are broken up into the following categories:
</p>
<ul>
<li>ad
<p>
Assembler/Disassembler tests. These tests verify that a
piece of LLVM assembly language can be assembled into
bytecode and then disassembled into the original
assembly language code. It does this several times to
ensure that assembled output can be disassembled and
disassembler output can be assembled. It also verifies
that the give assembly language file can be assembled
correctly.
</p>
<ul>
<li>Feature
<p>
These are the feature tests found in the Feature directory.
They are broken up into the following categories:
</p>
<ul>
<li>ad
<p>Assembler/Disassembler tests. These tests verify that a piece of LLVM
assembly language can be assembled into bytecode and then disassembled
into the original assembly language code. It does this several times to
ensure that assembled output can be disassembled and disassembler output
can be assembled. It also verifies that the give assembly language file
can be assembled correctly.</p></li>
<li>opt
<p>
Optimizer tests. These tests verify that two of the
optimizer passes completely optimize a program (i.e.
after a single pass, they cannot optimize a program
any further).
</p>
<li>opt
<p>Optimizer tests. These tests verify that two of the optimizer passes
completely optimize a program (i.e. after a single pass, they cannot
optimize a program any further).</p></li>
<li>mc
<p>
Machine code tests. These tests verify that the LLVM
assembly language file can be translated into native
assembly code.
</p>
<li>mc
<p> Machine code tests. These tests verify that the LLVM assembly
language file can be translated into native assembly code.</p></li>
<li>cc
<p>
C code tests. These tests verify that the specified
LLVM assembly code can be converted into C source code
using the C backend.
</p>
</ul>
<li>cc
<p>C code tests. These tests verify that the specified LLVM assembly
code can be converted into C source code using the C backend.</p></li>
</ul>
<p>
The LLVM database class looks at every file in the Feature
directory and creates a fake test hierarchy containing
<tt>Feature.&lt;testtype&gt;.&lt;testname&gt;</tt>. So, if you
add an LLVM assembly language file to the Feature directory, it
actually creates 5 new tests: assembler/disassembler, assembler,
optimizer, machine code, and C code.
</p>
<p>The LLVM database class looks at every file in the Feature directory and
creates a fake test hierarchy containing
<tt>Feature.&lt;testtype&gt;.&lt;testname&gt;</tt>. So, if you add an LLVM
assembly language file to the Feature directory, it actually creates 5 new
tests: assembler/disassembler, assembler, optimizer, machine code, and C code.
</p>
<li>Regression
<p>
These are the regression tests. There is one suite for each
subdirectory of the Regression directory. If you add a new
subdirectory there, you will need to modify, at least, the
<tt>RegressionMap</tt> variable in <tt>QMTest/llvmdb.py</tt> so
that QMTest knows how to run the tests in the new subdirectory.
</p>
</ul>
</div>
<li>Regression
<p>These are the regression tests. There is one suite for each
subdirectory of the Regression directory. If you add a new subdirectory
there, you will need to modify, at least, the <tt>RegressionMap</tt>
variable in <tt>QMTest/llvmdb.py</tt> so that QMTest knows how to run the
tests in the new subdirectory.</p>
<!--===============================================================-->
<div class="doc_section"><h2><a name="progstructure">Programs
Structure</a></div>
<!--===============================================================-->
</ul>
</div>
<div class="doc_text">
<p>
As mentioned previously, the Programs tree in llvm/test provides three
types of tests: MultiSource, SingleSource, and External. Each tree is
then subdivided into several categories, including applications,
benchmarks, regression tests, code that is strange grammatically, etc.
These organizations should be relatively self explanatory.
</p><p>
In addition to the regular Programs tests, the Programs tree also
provides a mechanism for compiling the programs in different ways. If
the variable TEST is defined on the gmake command line, the test system
will include a Makefile named <tt>TEST.&lt;value of TEST
variable&gt;.Makefile</tt>. This Makefile can modify build rules to
yield different results.
</p><p>
For example, the LLVM nightly tester uses <tt>TEST.nightly.Makefile</tt>
to create the nightly test reports. To run the nightly tests, run
<tt>gmake TEST=nightly</tt>.
</p><p>
There are several TEST Makefiles available in the tree. Some of them
are designed for internal LLVM research and will not work outside of the
LLVM research group. They may still be valuable, however, as a guide to
writing your own TEST Makefile for any optimization or analysis passes
that you develop with LLVM.
</p>
</div>
<!--===============================================================-->
<div class="doc_section"><a name="progstructure">Programs Structure</a></div>
<!--===============================================================-->
<!--===============================================================-->
<div class="doc_section"><h2><a name="run">Running the LLVM Tests</a>
</div>
<!--===============================================================-->
<div class="doc_text">
<div class="doc_text">
<p>
First, all tests are executed within the LLVM object directory tree.
They <i>are not</i> executed inside of the LLVM source tree. This is
because the test suite creates temporary files during execution.
</p><p>
The master Makefile in llvm/test is capable of running both the
QMTest driven tests and the Programs tests. By default, it will run
all of the tests.
</p><p>
To run only the QMTest driven tests, run <tt>gmake qmtest</tt> at the
command line in llvm/tests. To run a specific qmtest, suffix the test
name with ".t" when running gmake.
</p><p>
For example, to run the Regression.LLC tests, type
<tt>gmake Regression.LLC.t</tt> in llvm/tests.
</p><p>
Note that the Makefiles in llvm/test/Features and llvm/test/Regression
are gone. You must now use QMTest from the llvm/test directory to run
them.
</p><p>
To run the Programs test, cd into the llvm/test/Programs directory and
type <tt>gmake</tt>. Alternatively, you can type <tt>gmake
TEST=&lt;type&gt; test</tt> to run one of the specialized tests in
llvm/test/Programs/TEST.&lt;type&gt;.Makefile. For example, you could
run the nightly tester tests using the following commands:
</p>
<p>As mentioned previously, the Programs tree in llvm/test provides three types
of tests: MultiSource, SingleSource, and External. Each tree is then subdivided
into several categories, including applications, benchmarks, regression tests,
code that is strange grammatically, etc. These organizations should be
relatively self explanatory.</p>
<pre>
% cd llvm/test/Programs
% gmake TEST=nightly test
</pre>
<p>In addition to the regular Programs tests, the Programs tree also provides a
mechanism for compiling the programs in different ways. If the variable TEST is
defined on the gmake command line, the test system will include a Makefile named
<tt>TEST.&lt;value of TEST variable&gt;.Makefile</tt>. This Makefile can modify
build rules to yield different results.</p>
<p>For example, the LLVM nightly tester uses <tt>TEST.nightly.Makefile</tt> to
create the nightly test reports. To run the nightly tests, run <tt>gmake
TEST=nightly</tt>.</p>
<p>There are several TEST Makefiles available in the tree. Some of them are
designed for internal LLVM research and will not work outside of the LLVM
research group. They may still be valuable, however, as a guide to writing your
own TEST Makefile for any optimization or analysis passes that you develop with
LLVM.</p>
</div>
<!--===============================================================-->
<div class="doc_section"><a name="run">Running the LLVM Tests</a></div>
<!--===============================================================-->
<div class="doc_text">
<p>First, all tests are executed within the LLVM object directory tree. They
<i>are not</i> executed inside of the LLVM source tree. This is because the
test suite creates temporary files during execution. </p>
<p>The master Makefile in llvm/test is capable of running both the QMTest driven
tests and the Programs tests. By default, it will run all of the tests.</p>
<p>To run only the QMTest driven tests, run <tt>gmake qmtest</tt> at the
command line in llvm/tests. To run a specific qmtest, suffix the test name with
".t" when running gmake.</p>
<p>For example, to run the Regression.LLC tests, type <tt>gmake
Regression.LLC.t</tt> in llvm/tests.</p>
<p>Note that the Makefiles in llvm/test/Features and llvm/test/Regression are
gone. You must now use QMTest from the llvm/test directory to run them.</p>
<p>To run the Programs test, cd into the llvm/test/Programs directory and type
<tt>gmake</tt>. Alternatively, you can type <tt>gmake TEST=&lt;type&gt;
test</tt> to run one of the specialized tests in
llvm/test/Programs/TEST.&lt;type&gt;.Makefile. For example, you could run the
nightly tester tests using the following commands:</p>
<pre>
% cd llvm/test/Programs
% gmake TEST=nightly test
</pre>
<p>Regardless of which test you're running, the results are printed on standard
output and standard error. You can redirect these results to a file if you
choose.</p>
<p>Some tests are known to fail. Some are bugs that we have not fixed yet;
others are features that we haven't added yet (or may never add). In QMTest,
the result for such tests will be XFAIL (eXpected FAILure). In this way, you
can tell the difference between an expected and unexpected failure.</p>
<p>The Programs tests have no such feature as of this time. If the test passes,
only warnings and other miscellaneous output will be generated. If a test
fails, a large &lt;program&gt; FAILED message will be displayed. This will help
you separate benign warnings from actual test failures.</p>
</div>
<p>
Regardless of which test you're running, the results are printed on
standard output and standard error. You can redirect these results to a
file if you choose.
</p><p>
Some tests are known to fail. Some are bugs that we have not fixed yet;
others are features that we haven't added yet (or may never add). In
QMTest, the result for such tests will be XFAIL (eXpected FAILure). In
this way, you can tell the difference between an expected and unexpected
failure.
</p><p>
The Programs tests have no such feature as of this time. If the test
passes, only warnings and other miscellaneous output will be generated.
If a test fails, a large &lt;program&gt; FAILED message will be
displayed. This will help you separate benign warnings from actual test
failures.
</p>
</div>
<!-- *********************************************************************** -->
<hr>
<address>
<a href="http://jigsaw.w3.org/css-validator/check/referer"><img
src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
<a href="http://validator.w3.org/check/referer"><img
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
<hr><font size="-1">
<address>John T. Criswell</address>
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
<br>
Last modified: $Date$
</font>
John T. Criswell<br>
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
Last modified: $Date$
</address>
</body>
</html>

File diff suppressed because it is too large Load Diff

View File

@@ -201,7 +201,7 @@ DISTRIBUTE_GROUP_DOC = NO
# The TAB_SIZE tag can be used to set the number of spaces in a tab.
# Doxygen uses this value to replace tabs by spaces in code fragments.
TAB_SIZE = 2
TAB_SIZE = 8
# The GENERATE_TODOLIST tag can be used to enable (YES) or
# disable (NO) the todo list. This list is created by putting \todo
@@ -301,7 +301,7 @@ WARN_LOGFILE =
# directories like "/usr/src/myproject". Separate the files or directories with
# spaces.
INPUT = .. ./doxygen.intro
INPUT = ..
# If the value of the INPUT tag contains directories, you can use the
# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
@@ -439,20 +439,20 @@ HTML_OUTPUT = .
# each generated HTML page. If it is left blank doxygen will generate a
# standard header.
HTML_HEADER = doxygen.header
HTML_HEADER =
# The HTML_FOOTER tag can be used to specify a personal HTML footer for
# each generated HTML page. If it is left blank doxygen will generate a
# standard footer.
HTML_FOOTER = doxygen.footer
HTML_FOOTER =
# The HTML_STYLESHEET tag can be used to specify a user defined cascading
# style sheet that is used by each HTML page. It can be used to
# fine-tune the look of the HTML output. If the tag is left blank doxygen
# will generate a default style sheet
HTML_STYLESHEET = doxygen.css
HTML_STYLESHEET =
# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes,
# files or namespaces will be aligned in HTML using tables. If set to

View File

@@ -1,84 +0,0 @@
BODY { background: white; color: black; font-family: Verdana,Arial,sans-serif; }
H1 { text-align: center; }
H2 { text-align: center; }
H3 { text-align: center; }
CAPTION { font-weight: bold }
A.qindex {}
A.qindexRef {}
A.el { text-decoration: none; font-weight: bold }
A.elRef { font-weight: bold }
A.code { text-decoration: none; font-weight: normal; color: #4444ee }
A.codeRef { font-weight: normal; color: #4444ee }
A:link {
cursor: pointer;
text-decoration: none;
font-weight: bolder;
}
A:visited {
cursor: pointer;
text-decoration: underline;
font-weight: bolder;
}
A:hover {
cursor: pointer;
text-decoration: underline;
font-weight: bolder;
}
A:active {
cursor: pointer;
text-decoration: underline;
font-weight: bolder;
font-style: italic;
}
DL.el { margin-left: -1cm }
DIV.fragment { width: 100%; border: none; background-color: #eeeeee }
DIV.ah { background-color: black; font-weight: bold; color: #ffffff; margin-bottom: 3px; margin-top: 3px }
TD.md { background-color: #f2f2ff; font-weight: bold; }
TD.mdname1 { background-color: #f2f2ff; font-weight: bold; color: #602020; }
TD.mdname { background-color: #f2f2ff; font-weight: bold; color: #602020; width: 600px; }
DIV.groupHeader { margin-left: 16px; margin-top: 12px; margin-bottom: 6px; font-weight: bold }
DIV.groupText { margin-left: 16px; font-style: italic; font-size: smaller }
TD.indexkey {
background-color: #eeeeff;
font-weight: bold;
padding-right : 10px;
padding-top : 2px;
padding-left : 10px;
padding-bottom : 2px;
margin-left : 0px;
margin-right : 0px;
margin-top : 2px;
margin-bottom : 2px
}
TD.indexvalue {
background-color: #eeeeff;
font-style: italic;
padding-right : 10px;
padding-top : 2px;
padding-left : 10px;
padding-bottom : 2px;
margin-left : 0px;
margin-right : 0px;
margin-top : 2px;
margin-bottom : 2px
}
span.keyword { color: #008000 }
span.keywordtype { color: #604020 }
span.keywordflow { color: #e08000 }
span.comment { color: #800000 }
span.preprocessor { color: #806020 }
span.stringliteral { color: #002080 }
span.charliteral { color: #008080 }
.footer {
font-size: 80%;
font-weight: bold;
text-align: center;
vertical-align: middle;
}
.title {
font-size: 105%
font-weight: bold;
text-decoration: underline;
text-align: center;
}

View File

@@ -1,9 +0,0 @@
<hr>
<p class="footer">
Generated on $datetime for $projectname version $projectnumber by
<a href="http://www.doxygen.org/index.html">doxygen $doxygenversion</a><br/>
Copyright &copy; 2003, University of Illinois at Urbana-Champaign. All Rights Reserved.<br/>
<a href="/index.php" onmouseover="window.status='Go To LLVM Home Page';return true;" title="LLVM Home Page">Home Page</a>
<a href="http://www.doxygen.org/index.html" onmouseover="window.status='Go To Doxygen Home Page';return true;" title="Doxygen Home Page">
<img src="doxygen.png" alt="Doxygen Logo" style="border:none;"/></a>
</p></body></html>

View File

@@ -1,9 +0,0 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html><head>
<meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1"/>
<meta name="keywords" content="LLVM,Low Level Virtual Machine,C++,doxygen,API,documentation"/>
<meta name="description" content="C++ source code API documentation for the Low Level Virtual Machine (LLVM)."/>
<title>LLVM: $title</title>
<link href="doxygen.css" rel="stylesheet" type="text/css"/>
</head><body>
<p class="title">LLVM API Documentation</p>

View File

@@ -1,25 +0,0 @@
////////////////////////////////////////////////////////////////////////////////
/// @file doxygen.intro
/// @author Reid Spencer <rspencer@x10sys.com>
/// @date 2003/12/30
/// @brief LLVM API documentation introduction.
////////////////////////////////////////////////////////////////////////////////
///
/// @mainpage LLVM:Low Level Virtual Machine
///
/// @section main_intro Introduction
/// Welcome to the Low Level Virtual Machine (LLVM)
///
/// This documentation describes the @b internal software that makes
/// up LLVM, not the @b external use of LLVM. There are no instructions
/// here on how to use LLVM, only the APIs that make up the software. For usage
/// instructions, please see the programmer's guide or reference manual.
///
/// @section main_caveat Caveat
/// This documentation is generated directly from the source code with doxygen.
/// Since LLVM is constantly under active development, what you're about to
/// read is out of date! However, it may still be useful since certain portions of
/// LLVM are very stable.
///
/// @section main_changelog Change Log
/// - Original content written 12/30/2003 by Reid Spencer

View File

@@ -48,7 +48,7 @@ Getting Started with LLVM
<dt>
For license information:
<dd>
<a href="http://llvm.cs.uiuc.edu/cvsweb/cvsweb.cgi/llvm/LICENSE.TXT?rev=HEAD&content-type=text/x-cvsweb-markup">llvm/LICENSE.TXT</a>
<a href="../LICENSE.TXT">llvm/LICENSE.TXT</a>
<p>
<dt>
@@ -120,11 +120,11 @@ LLVM Design Overview:
<dl compact>
<dt>
LLVM: A Compilation Framework for Lifelong Program Analysis
&amp; Transformation
LLVM : A Compilation Framework for Lifelong Program Analysis
and Transformation:
<dd>
<a href="http://llvm.cs.uiuc.edu/pubs/2004-01-30-CGO-LLVM.html">
http://llvm.cs.uiuc.edu/pubs/2004-01-30-CGO-LLVM.html </a>
<a href="http://llvm.cs.uiuc.edu/pubs/2003-09-30-LifelongOptimizationTR.html">
http://llvm.cs.uiuc.edu/pubs/2003-09-30-LifelongOptimizationTR.html </a>
</dl>
@@ -182,20 +182,6 @@ LLVM Programming Documentation:
<a href="AliasAnalysis.html"> llvm/docs/AliasAnalysis.html</a>
<p>
<dt>
Source Level Debugging with LLVM:
<dd>
<a href="SourceLevelDebugging.html"> llvm/docs/SourceLevelDebugging.html</a>
<p>
<dt>
TableGen Fundamentals:
<dd>
<a href="TableGenFundamentals.html"> llvm/docs/TableGenFundamentals.html</a>
<p>
<dt>
The Stacker Cronicles
<dd>

View File

@@ -47,6 +47,5 @@ address { clear: right; }
.doc_red { color: red }
.doc_table { text-align: center; width: 90%;
padding: 1px 1px 1px 1px; border: 1px; }
.doc_table { text-align: center; width: 90%; padding: 1 1 1 1; border: 1 1 1 1 ; }

Binary file not shown.

Before

Width:  |  Height:  |  Size: 55 KiB

View File

@@ -8,6 +8,12 @@
/* Define to 1 if using `alloca.c'. */
#undef C_ALLOCA
/* Define if the machine is Big-Endian */
#undef ENDIAN_BIG
/* Define if the machine is Little-Endian */
#undef ENDIAN_LITTLE
/* Define to 1 if you have `alloca', as a function or macro. */
#undef HAVE_ALLOCA
@@ -15,8 +21,11 @@
*/
#undef HAVE_ALLOCA_H
/* Define to 1 if you have the `backtrace' function. */
#undef HAVE_BACKTRACE
/* Define to 1 if you have the <assert.h> header file. */
#undef HAVE_ASSERT_H
/* define if the compiler has bidirectional iterator */
#undef HAVE_BI_ITERATOR
/* Define to 1 if you have the <dlfcn.h> header file. */
#undef HAVE_DLFCN_H
@@ -24,12 +33,18 @@
/* Define if dlopen() is available on this platform. */
#undef HAVE_DLOPEN
/* Define to 1 if you have the <execinfo.h> header file. */
#undef HAVE_EXECINFO_H
/* Define to 1 if you have the <errno.h> header file. */
#undef HAVE_ERRNO_H
/* define if the compiler has ext/slist */
#undef HAVE_EXT_SLIST
/* Define to 1 if you have the <fcntl.h> header file. */
#undef HAVE_FCNTL_H
/* define if the compiler has STL iterators */
#undef HAVE_FWD_ITERATOR
/* Define to 1 if you have the `getcwd' function. */
#undef HAVE_GETCWD
@@ -39,6 +54,22 @@
/* Define to 1 if you have the `gettimeofday' function. */
#undef HAVE_GETTIMEOFDAY
/* Define if the compiler has a header <hash_map> that defines template class
::hash_map. */
#undef HAVE_GLOBAL_HASH_MAP
/* Define if the compiler has a header <hash_set> that defines template class
::hash_set. */
#undef HAVE_GLOBAL_HASH_SET
/* Define if the compiler has a header <ext/hash_map> that defines template
class __gnu_cxx::hash_map. */
#undef HAVE_GNU_EXT_HASH_MAP
/* Define if the compiler has a header <ext/hash_set> that defines template
class __gnu_cxx::hash_set. */
#undef HAVE_GNU_EXT_HASH_SET
/* Define to 1 if the system has the type `int64_t'. */
#undef HAVE_INT64_T
@@ -64,6 +95,9 @@
/* Define to 1 if you have the <malloc.h> header file. */
#undef HAVE_MALLOC_H
/* Define to 1 if you have the <math.h> header file. */
#undef HAVE_MATH_H
/* Define to 1 if you have the <memory.h> header file. */
#undef HAVE_MEMORY_H
@@ -83,21 +117,57 @@
/* Define to have the %a format string */
#undef HAVE_PRINTF_A
/* Define if PThread mutexes (e.g., pthread_mutex_lock) are available in the
system's thread library. */
#undef HAVE_PTHREAD_MUTEX_LOCK
/* Define to 1 if you have the <signal.h> header file. */
#undef HAVE_SIGNAL_H
/* Define to 1 if you have the <stdint.h> header file. */
#undef HAVE_STDINT_H
/* Define to 1 if you have the <stdlib.h> header file. */
#undef HAVE_STDLIB_H
/* Define if the compiler has a header <ext/hash_map> that defines template
class std::hash_map. */
#undef HAVE_STD_EXT_HASH_MAP
/* Define if the compiler has a header <ext/hash_set> that defines template
class std::hash_set. */
#undef HAVE_STD_EXT_HASH_SET
/* define if the compiler has STL iterators */
#undef HAVE_STD_ITERATOR
/* Define to 1 if you have the `strcspn' function. */
#undef HAVE_STRCSPN
/* Define to 1 if you have the `strdup' function. */
#undef HAVE_STRDUP
/* Define to 1 if you have the `strerror' function. */
#undef HAVE_STRERROR
/* Define to 1 if you have the <strings.h> header file. */
#undef HAVE_STRINGS_H
/* Define to 1 if you have the <string.h> header file. */
#undef HAVE_STRING_H
/* Define to 1 if you have the `strspn' function. */
#undef HAVE_STRSPN
/* Define to 1 if you have the `strstr' function. */
#undef HAVE_STRSTR
/* Define to 1 if you have the `strtod' function. */
#undef HAVE_STRTOD
/* Define to 1 if you have the `strtol' function. */
#undef HAVE_STRTOL
/* Define to 1 if you have the `strtoll' function. */
#undef HAVE_STRTOLL
@@ -146,9 +216,6 @@
/* Define as the return type of signal handlers (`int' or `void'). */
#undef RETSIGTYPE
/* Extension that shared libraries have, e.g., ".so". */
#undef SHLIBEXT
/* If using the C implementation of alloca, define if you know the
direction of stack growth for your system; otherwise it will be
automatically deduced at run-time.
@@ -170,6 +237,13 @@
`char[]'. */
#undef YYTEXT_POINTER
/* Define to empty if `const' does not conform to ANSI C. */
#undef const
/* Define as `__inline' if that's what the C compiler calls it, or to nothing
if it is not supported. */
#undef inline
/* Define to `int' if <sys/types.h> does not define. */
#undef pid_t

View File

@@ -0,0 +1,23 @@
/*
* The LLVM Compiler Infrastructure
*
* This file was developed by the LLVM research group and is distributed under
* the University of Illinois Open Source License. See LICENSE.TXT for details.
*
******************************************************************************
*
* Description:
* This header file is the autoconf replacement for errno.h (if it lives
* on the system).
*/
#ifndef _CONFIG_ERRNO_H
#define _CONFIG_ERRNO_H
#include "Config/config.h"
#ifdef HAVE_ERRNO_H
#include <errno.h>
#endif
#endif

View File

@@ -0,0 +1,23 @@
/*
* The LLVM Compiler Infrastructure
*
* This file was developed by the LLVM research group and is distributed under
* the University of Illinois Open Source License. See LICENSE.TXT for details.
*
*===----------------------------------------------------------------------===//
*
* Description:
* This header file is the autoconf replacement for stdlib.h (if it lives
* on the system).
*/
#ifndef _CONFIG_STDLIB_H
#define _CONFIG_STDLIB_H
#include "Config/config.h"
#ifdef HAVE_STDLIB_H
#include <stdlib.h>
#endif
#endif

View File

@@ -0,0 +1,23 @@
/*
* The LLVM Compiler Infrastructure
*
* This file was developed by the LLVM research group and is distributed under
* the University of Illinois Open Source License. See LICENSE.TXT for details.
*
*===----------------------------------------------------------------------===//
*
* Description:
* This header file is the autoconf replacement for string.h (if it lives
* on the system).
*/
#ifndef _CONFIG_STRING_H
#define _CONFIG_STRING_H
#include "Config/config.h"
#ifdef HAVE_STRING_H
#include <string.h>
#endif
#endif

View File

@@ -1,4 +1,4 @@
/*===-- Config/sys/resource.h -----------------------------------*- C++ -*-===//
/*===-- Config/sys/resource.h - Annotation classes --------------*- C++ -*-===//
*
* The LLVM Compiler Infrastructure
*

View File

@@ -1,4 +1,4 @@
/*===-- Config/sys/stat.h -----------------------------------*- ----C++ -*-===//
/*===-- Config/sys/stat.h - Annotation classes --------------*- ----C++ -*-===//
*
* The LLVM Compiler Infrastructure
*

View File

@@ -1,4 +1,4 @@
/*===-- Config/sys/time.h ---------------------------------------*- C++ -*-===//
/*===-- Config/sys/time.h - Annotation classes ------------------*- C++ -*-===//
*
* The LLVM Compiler Infrastructure
*

View File

@@ -1,4 +1,4 @@
/*===-- Config/sys/types.h --------------------------------------*- C++ -*-===//
/*===-- Config/sys/types.h - Annotation classes --------------*- C++ -*-===//
*
* The LLVM Compiler Infrastructure
*

View File

@@ -1,4 +1,4 @@
/*===-- Config/sys/wait.h ---------------------------------------*- C++ -*-===//
/*===-- Config/sys/wait.h - Annotation classes ------------------*- C++ -*-===//
*
* The LLVM Compiler Infrastructure
*

View File

@@ -68,7 +68,7 @@ class Annotation {
Annotation *Next; // The next annotation in the linked list
public:
inline Annotation(AnnotationID id) : ID(id), Next(0) {}
virtual ~Annotation(); // Designed to be subclassed
virtual ~Annotation() {} // Designed to be subclassed
// getID - Return the unique ID# of this annotation
inline AnnotationID getID() const { return ID; }
@@ -95,7 +95,14 @@ class Annotable {
void operator=(const Annotable &); // Do not implement
public:
Annotable() : AnnotationList(0) {}
virtual ~Annotable(); // Virtual because it's designed to be subclassed...
virtual ~Annotable() { // Virtual because it's designed to be subclassed...
Annotation *A = AnnotationList;
while (A) {
Annotation *Next = A->getNext();
delete A;
A = Next;
}
}
// getAnnotation - Search the list for annotations of the specified ID. The
// pointer returned is either null (if no annotations of the specified ID

View File

@@ -20,15 +20,14 @@
#ifndef SUPPORT_COMMANDLINE_H
#define SUPPORT_COMMANDLINE_H
#include "Support/type_traits.h"
#include <string>
#include <vector>
#include <utility>
#include <cstdarg>
#include <cassert>
#include "boost/type_traits/object_traits.hpp"
namespace llvm {
/// cl Namespace - This namespace contains all of the command line option
/// processing machinery. It is intentionally a short name to make qualified
/// usage concise.
@@ -720,7 +719,7 @@ template <class DataType, bool ExternalStorage = false,
class ParserClass = parser<DataType> >
class opt : public Option,
public opt_storage<DataType, ExternalStorage,
is_class<DataType>::value> {
::boost::is_class<DataType>::value> {
ParserClass Parser;
virtual bool handleOccurrence(const char *ArgName, const std::string &Arg) {

View File

@@ -11,6 +11,7 @@
// This file is important because different host OS's define different macros,
// which makes portability tough. This file exports the following definitions:
//
// ENDIAN_LITTLE : is #define'd if the host is little endian
// int64_t : is a typedef for the signed 64 bit system type
// uint64_t : is a typedef for the unsigned 64 bit system type
// INT64_MAX : is a #define specifying the max value for int64_t's
@@ -22,24 +23,39 @@
#ifndef SUPPORT_DATATYPES_H
#define SUPPORT_DATATYPES_H
#include "Config/config.h"
// Note that this header's correct operation depends on __STDC_LIMIT_MACROS
// being defined. We would define it here, but in order to prevent Bad Things
// happening when system headers or C++ STL headers include stdint.h before
// we define it here, we define it on the g++ command line (in Makefile.rules).
#if !defined(__STDC_LIMIT_MACROS)
# error "Must #define __STDC_LIMIT_MACROS before #including Support/DataTypes.h"
#ifdef HAVE_STDINT_H
#include <stdint.h>
#endif
// Note that <inttypes.h> includes <stdint.h>, if this is a C99 system.
@INCLUDE_INTTYPES_H@
@INCLUDE_SYS_TYPES_H@
#ifdef HAVE_INTTYPES_H
#include <inttypes.h>
#endif
#ifdef HAVE_SYS_TYPES_H
#include <sys/types.h>
#endif
#if (defined(ENDIAN_LITTLE) && defined(ENDIAN_BIG))
#error "Cannot define both ENDIAN_LITTLE and ENDIAN_BIG!"
#endif
#if (!defined(ENDIAN_LITTLE) && !defined(ENDIAN_BIG))
#error "include/Support/DataTypes.h could not determine endianness!"
#endif
#if !defined(INT64_MAX)
/* We couldn't determine INT64_MAX; default it. */
# define INT64_MAX 9223372036854775807LL
#define INT64_MAX 9223372036854775807LL
#endif
#if !defined(UINT64_MAX)
# define UINT64_MAX 0xffffffffffffffffULL
#define UINT64_MAX 0xffffffffffffffffULL
#endif
#endif /* SUPPORT_DATATYPES_H */

View File

@@ -1,63 +0,0 @@
//===- DenseMap.h - A dense map implmentation -------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file was developed by the LLVM research group and is distributed under
// the University of Illinois Open Source License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This file implements a dense map. A dense map template takes two
// types. The first is the mapped type and the second is a functor
// that maps its argument to a size_t. On instantiation a "null" value
// can be provided to be used as a "does not exist" indicator in the
// map. A member function grow() is provided that given the value of
// the maximally indexed key (the argument of the functor) makes sure
// the map has enough space for it.
//
//===----------------------------------------------------------------------===//
#ifndef SUPPORT_DENSEMAP_H
#define SUPPORT_DENSEMAP_H
#include <vector>
namespace llvm {
template <typename T, typename ToIndexT>
class DenseMap {
typedef typename ToIndexT::argument_type IndexT;
typedef std::vector<T> StorageT;
StorageT storage_;
T nullVal_;
ToIndexT toIndex_;
public:
DenseMap() : nullVal_(T()) { }
explicit DenseMap(const T& val) : nullVal_(val) { }
typename StorageT::reference operator[](IndexT n) {
assert(toIndex_(n) < storage_.size() && "index out of bounds!");
return storage_[toIndex_(n)];
}
typename StorageT::const_reference operator[](IndexT n) const {
assert(toIndex_(n) < storage_.size() && "index out of bounds!");
return storage_[toIndex_(n)];
}
void clear() {
storage_.clear();
}
void grow(IndexT n) {
unsigned NewSize = toIndex_(n) + 1;
if (NewSize > storage_.size())
storage_.resize(NewSize, nullVal_);
}
};
} // End llvm namespace
#endif

View File

@@ -1,295 +0,0 @@
//===-- Support/ELF.h - ELF constants and data structures -------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file was developed by the LLVM research group and is distributed under
// the University of Illinois Open Source License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This header contains common, non-processor-specific data structures and
// constants for the ELF file format.
//
// The details of the ELF32 bits in this file are largely based on
// the Tool Interface Standard (TIS) Executable and Linking Format
// (ELF) Specification Version 1.2, May 1995. The ELF64 stuff is not
// standardized, as far as I can tell. It was largely based on information
// I found in OpenBSD header files.
//
//===----------------------------------------------------------------------===//
#include "Support/DataTypes.h"
#include <cstring>
#include <cstdlib>
namespace llvm {
namespace ELF {
typedef uint32_t Elf32_Addr; // Program address
typedef uint16_t Elf32_Half;
typedef uint32_t Elf32_Off; // File offset
typedef int32_t Elf32_Sword;
typedef uint32_t Elf32_Word;
typedef uint64_t Elf64_Addr;
typedef uint64_t Elf64_Off;
typedef int32_t Elf64_Shalf;
typedef int32_t Elf64_Sword;
typedef uint32_t Elf64_Word;
typedef int64_t Elf64_Sxword;
typedef uint64_t Elf64_Xword;
typedef uint32_t Elf64_Half;
typedef uint16_t Elf64_Quarter;
// Object file magic string.
static const char ElfMagic[] = { 0x7f, 'E', 'L', 'F', '\0' };
struct Elf32_Ehdr {
unsigned char e_ident[16]; // ELF Identification bytes
Elf32_Half e_type; // Type of file (see ET_* below)
Elf32_Half e_machine; // Required architecture for this file (see EM_*)
Elf32_Word e_version; // Must be equal to 1
Elf32_Addr e_entry; // Address to jump to in order to start program
Elf32_Off e_phoff; // Program header table's file offset, in bytes
Elf32_Off e_shoff; // Section header table's file offset, in bytes
Elf32_Word e_flags; // Processor-specific flags
Elf32_Half e_ehsize; // Size of ELF header, in bytes
Elf32_Half e_phentsize; // Size of an entry in the program header table
Elf32_Half e_phnum; // Number of entries in the program header table
Elf32_Half e_shentsize; // Size of an entry in the section header table
Elf32_Half e_shnum; // Number of entries in the section header table
Elf32_Half e_shstrndx; // Sect hdr table index of sect name string table
bool checkMagic () const {
return (memcmp (e_ident, ElfMagic, strlen (ElfMagic))) == 0;
}
unsigned char getFileClass () const { return e_ident[4]; }
unsigned char getDataEncoding () { return e_ident[5]; }
};
// 64-bit ELF header. Fields are the same as for ELF32, but with different
// types (see above).
struct Elf64_Ehdr {
unsigned char e_ident[16];
Elf64_Quarter e_type;
Elf64_Quarter e_machine;
Elf64_Half e_version;
Elf64_Addr e_entry;
Elf64_Off e_phoff;
Elf64_Off e_shoff;
Elf64_Half e_flags;
Elf64_Quarter e_ehsize;
Elf64_Quarter e_phentsize;
Elf64_Quarter e_phnum;
Elf64_Quarter e_shentsize;
Elf64_Quarter e_shnum;
Elf64_Quarter e_shstrndx;
};
// File types
enum {
ET_NONE = 0, // No file type
ET_REL = 1, // Relocatable file
ET_EXEC = 2, // Executable file
ET_DYN = 3, // Shared object file
ET_CORE = 4, // Core file
ET_LOPROC = 0xff00, // Beginning of processor-specific codes
ET_HIPROC = 0xffff // Processor-specific
};
// Machine architectures
enum {
EM_NONE = 0, // No machine
EM_M32 = 1, // AT&T WE 32100
EM_SPARC = 2, // SPARC
EM_386 = 3, // Intel 386
EM_68K = 4, // Motorola 68000
EM_88K = 5, // Motorola 88000
EM_486 = 6, // Intel 486 (deprecated)
EM_860 = 7, // Intel 80860
EM_MIPS = 8, // MIPS R3000
EM_PPC = 20, // PowerPC
EM_ARM = 40, // ARM
EM_ALPHA = 41, // DEC Alpha
EM_SPARCV9 = 43 // SPARC V9
};
// Object file classes.
enum {
ELFCLASS32 = 1, // 32-bit object file
ELFCLASS64 = 2 // 64-bit object file
};
// Object file byte orderings.
enum {
ELFDATA2LSB = 1, // Little-endian object file
ELFDATA2MSB = 2 // Big-endian object file
};
// Section header.
struct Elf32_Shdr {
Elf32_Word sh_name; // Section name (index into string table)
Elf32_Word sh_type; // Section type (SHT_*)
Elf32_Word sh_flags; // Section flags (SHF_*)
Elf32_Addr sh_addr; // Address where section is to be loaded
Elf32_Off sh_offset; // File offset of section data, in bytes
Elf32_Word sh_size; // Size of section, in bytes
Elf32_Word sh_link; // Section type-specific header table index link
Elf32_Word sh_info; // Section type-specific extra information
Elf32_Word sh_addralign; // Section address alignment
Elf32_Word sh_entsize; // Size of records contained within the section
};
// Section header for ELF64 - same fields as ELF32, different types.
struct Elf64_Shdr {
Elf64_Half sh_name;
Elf64_Half sh_type;
Elf64_Xword sh_flags;
Elf64_Addr sh_addr;
Elf64_Off sh_offset;
Elf64_Xword sh_size;
Elf64_Half sh_link;
Elf64_Half sh_info;
Elf64_Xword sh_addralign;
Elf64_Xword sh_entsize;
};
// Special section indices.
enum {
SHN_UNDEF = 0, // Undefined, missing, irrelevant, or meaningless
SHN_LORESERVE = 0xff00, // Lowest reserved index
SHN_LOPROC = 0xff00, // Lowest processor-specific index
SHN_HIPROC = 0xff1f, // Highest processor-specific index
SHN_ABS = 0xfff1, // Symbol has absolute value; does not need relocation
SHN_COMMON = 0xfff2, // FORTRAN COMMON or C external global variables
SHN_HIRESERVE = 0xffff // Highest reserved index
};
// Section types.
enum {
SHT_NULL = 0, // No associated section (inactive entry).
SHT_PROGBITS = 1, // Program-defined contents.
SHT_SYMTAB = 2, // Symbol table.
SHT_STRTAB = 3, // String table.
SHT_RELA = 4, // Relocation entries; explicit addends.
SHT_HASH = 5, // Symbol hash table.
SHT_DYNAMIC = 6, // Information for dynamic linking.
SHT_NOTE = 7, // Information about the file.
SHT_NOBITS = 8, // Data occupies no space in the file.
SHT_REL = 9, // Relocation entries; no explicit addends.
SHT_SHLIB = 10, // Reserved.
SHT_DYNSYM = 11, // Symbol table.
SHT_LOPROC = 0x70000000, // Lowest processor architecture-specific type.
SHT_HIPROC = 0x7fffffff, // Highest processor architecture-specific type.
SHT_LOUSER = 0x80000000, // Lowest type reserved for applications.
SHT_HIUSER = 0xffffffff // Highest type reserved for applications.
};
// Section flags.
enum {
SHF_WRITE = 0x1, // Section data should be writable during execution.
SHF_ALLOC = 0x2, // Section occupies memory during program execution.
SHF_EXECINSTR = 0x4, // Section contains executable machine instructions.
SHF_MASKPROC = 0xf0000000 // Bits indicating processor-specific flags.
};
// Symbol table entries.
struct Elf32_Sym {
Elf32_Word st_name; // Symbol name (index into string table)
Elf32_Addr st_value; // Value or address associated with the symbol
Elf32_Word st_size; // Size of the symbol
unsigned char st_info; // Symbol's type and binding attributes
unsigned char st_other; // Must be zero; reserved
Elf32_Half st_shndx; // Which section (header table index) it's defined in
// These accessors and mutators correspond to the ELF32_ST_BIND,
// ELF32_ST_TYPE, and ELF32_ST_INFO macros defined in the ELF specification:
unsigned char getBinding () const { return st_info >> 4; }
unsigned char getType () const { return st_info & 0x0f; }
void setBinding (unsigned char b) { setBindingAndType (b, getType ()); }
void setType (unsigned char t) { setBindingAndType (getBinding (), t); }
void setBindingAndType (unsigned char b, unsigned char t) {
st_info = (b << 4) + (t & 0x0f);
}
};
// Symbol bindings.
enum {
STB_LOCAL = 0, // Local symbol, not visible outside obj file containing def
STB_GLOBAL = 1, // Global symbol, visible to all object files being combined
STB_WEAK = 2, // Weak symbol, like global but lower-precedence
STB_LOPROC = 13, // Lowest processor-specific binding type
STB_HIPROC = 15 // Highest processor-specific binding type
};
// Symbol types.
enum {
STT_NOTYPE = 0, // Symbol's type is not specified
STT_OBJECT = 1, // Symbol is a data object (variable, array, etc.)
STT_FUNC = 2, // Symbol is executable code (function, etc.)
STT_SECTION = 3, // Symbol refers to a section
STT_FILE = 4, // Local, absolute symbol that refers to a file
STT_LOPROC = 13, // Lowest processor-specific symbol type
STT_HIPROC = 15 // Highest processor-specific symbol type
};
// Relocation entry, without explicit addend.
struct Elf32_Rel {
Elf32_Addr r_offset; // Location (file byte offset, or program virtual addr)
Elf32_Word r_info; // Symbol table index and type of relocation to apply
// These accessors and mutators correspond to the ELF32_R_SYM, ELF32_R_TYPE,
// and ELF32_R_INFO macros defined in the ELF specification:
Elf32_Word getSymbol () const { return (r_info >> 8); }
unsigned char getType () const { return (unsigned char) (r_info & 0x0ff); }
void setSymbol (Elf32_Word s) { setSymbolAndType (s, getType ()); }
void setType (unsigned char t) { setSymbolAndType (getSymbol(), t); }
void setSymbolAndType (Elf32_Word s, unsigned char t) {
r_info = (s << 8) + t;
};
};
// Relocation entry with explicit addend.
struct Elf32_Rela {
Elf32_Addr r_offset; // Location (file byte offset, or program virtual addr)
Elf32_Word r_info; // Symbol table index and type of relocation to apply
Elf32_Sword r_addend; // Compute value for relocatable field by adding this
// These accessors and mutators correspond to the ELF32_R_SYM, ELF32_R_TYPE,
// and ELF32_R_INFO macros defined in the ELF specification:
Elf32_Word getSymbol () const { return (r_info >> 8); }
unsigned char getType () const { return (unsigned char) (r_info & 0x0ff); }
void setSymbol (Elf32_Word s) { setSymbolAndType (s, getType ()); }
void setType (unsigned char t) { setSymbolAndType (getSymbol(), t); }
void setSymbolAndType (Elf32_Word s, unsigned char t) {
r_info = (s << 8) + t;
};
};
// Program header.
struct Elf32_Phdr {
Elf32_Word p_type; // Type of segment
Elf32_Off p_offset; // File offset where segment is located, in bytes
Elf32_Addr p_vaddr; // Virtual address of beginning of segment
Elf32_Addr p_paddr; // Physical address of beginning of segment (OS-specific)
Elf32_Word p_filesz; // Num. of bytes in file image of segment (may be zero)
Elf32_Word p_memsz; // Num. of bytes in mem image of segment (may be zero)
Elf32_Word p_flags; // Segment flags
Elf32_Word p_align; // Segment alignment constraint
};
enum {
PT_NULL = 0, // Unused segment.
PT_LOAD = 1, // Loadable segment.
PT_DYNAMIC = 2, // Dynamic linking information.
PT_INTERP = 3, // Interpreter pathname.
PT_NOTE = 4, // Auxiliary information.
PT_SHLIB = 5, // Reserved.
PT_PHDR = 6, // The program header table itself.
PT_LOPROC = 0x70000000, // Lowest processor-specific program hdr entry type.
PT_HIPROC = 0x7fffffff // Highest processor-specific program hdr entry type.
};
} // end namespace ELF
} // end namespace llvm

View File

@@ -70,87 +70,38 @@ void removeFile(const std::string &Filename);
///
std::string getUniqueFilename(const std::string &FilenameBase);
/// MakeFileExecutable - This method turns on whatever access attributes are
/// needed to make the specified file executable. It returns true on success.
/// In case of failure, the file's access attributes are unspecified.
///
bool MakeFileExecutable(const std::string &Filename);
/// MakeFileReadable - This method turns on whatever access attributes are
/// needed to make the specified file readable. It returns true on success.
/// In case of failure, the file's access attributes are unspecified.
/// Method: MakeFileExecutable()
///
bool MakeFileReadable(const std::string &Filename);
/// getFileSize - Return the size of the specified file in bytes, or -1 if the
/// file cannot be read or does not exist.
long long getFileSize(const std::string &Filename);
/// getFileTimestamp - Get the last modified time for the specified file in an
/// unspecified format. This is useful to allow checking to see if a file was
/// updated since that last time the timestampt was aquired. If the file does
/// not exist or there is an error getting the time-stamp, zero is returned.
unsigned long long getFileTimestamp(const std::string &Filename);
/// FDHandle - Simple handle class to make sure a file descriptor gets closed
/// when the object is destroyed. This handle acts similarly to an
/// std::auto_ptr, in that the copy constructor and assignment operators
/// transfer ownership of the handle. This means that FDHandle's do not have
/// value semantics.
/// Description:
/// This method turns on whatever access attributes are needed to make the
/// specified file executable.
///
class FDHandle {
int FD;
public:
FDHandle() : FD(-1) {}
FDHandle(int fd) : FD(fd) {}
FDHandle(FDHandle &RHS) : FD(RHS.FD) {
RHS.FD = -1; // Transfer ownership
}
/// Return value:
/// True - The operation succeeded.
/// False - The operation failed.
///
/// Notes:
/// In case of failure, the file's access attributes are unspecified.
///
bool MakeFileExecutable (const std::string & Filename);
~FDHandle() throw();
///
/// Method: MakeFileReadable()
///
/// Description:
/// This method turns on whatever access attributes are needed to make the
/// specified file readable.
///
/// Return value:
/// True - The operation succeeded.
/// False - The operation failed.
///
/// Notes:
/// In case of failure, the file's access attributes are unspecified.
///
bool MakeFileReadable (const std::string & Filename);
/// get - Get the current file descriptor, without releasing ownership of it.
int get() const { return FD; }
operator int() const { return FD; }
FDHandle &operator=(int fd) throw();
FDHandle &operator=(FDHandle &RHS) {
int fd = RHS.FD;
RHS.FD = -1; // Transfer ownership
return operator=(fd);
}
/// release - Take ownership of the file descriptor away from the FDHandle
/// object, so that the file is not closed when the FDHandle is destroyed.
int release() {
int Ret = FD;
FD = -1;
return Ret;
}
};
/// FileRemover - This class is a simple object meant to be stack allocated.
/// If an exception is thrown from a region, the object removes the filename
/// specified (if deleteIt is true).
///
class FileRemover {
std::string Filename;
bool DeleteIt;
public:
FileRemover(const std::string &filename, bool deleteIt = true)
: Filename(filename), DeleteIt(deleteIt) {}
~FileRemover() {
if (DeleteIt) removeFile(Filename);
}
/// releaseFile - Take ownership of the file away from the FileRemover so it
/// will not be removed when the object is destroyed.
void releaseFile() { DeleteIt = false; }
};
} // End llvm namespace
#endif

View File

@@ -117,7 +117,7 @@ public:
}
if (EI != EE)
O << "|<g64>truncated...";
O << "|truncated...";
O << "}";
}
O << "}\"];\n"; // Finish printing the "node" line
@@ -126,8 +126,6 @@ public:
EI = GTraits::child_begin(Node);
for (unsigned i = 0; EI != EE && i != 64; ++EI, ++i)
writeEdge(Node, i, EI);
for (; EI != EE; ++EI)
writeEdge(Node, 64, EI);
}
void writeEdge(NodeType *Node, unsigned edgeidx, child_iterator EI) {

View File

@@ -18,10 +18,6 @@
namespace llvm {
#if defined(log2)
# undef log2
#endif
inline unsigned log2(uint64_t C) {
unsigned getPow;
for (getPow = 0; C > 1; ++getPow)

View File

@@ -73,6 +73,9 @@ static inline void deleter(T *Ptr) {
// mapped_iterator - This is a simple iterator adapter that causes a function to
// be dereferenced whenever operator* is invoked on the iterator.
//
// It turns out that this is disturbingly similar to boost::transform_iterator
//
#if 1
template <class RootIt, class UnaryFunc>
class mapped_iterator {
RootIt current;
@@ -128,6 +131,28 @@ operator+(typename mapped_iterator<_Iterator, Func>::difference_type N,
return mapped_iterator<_Iterator, Func>(X.getCurrent() - N);
}
#else
// This fails to work, because some iterators are not classes, for example
// vector iterators are commonly value_type **'s
template <class RootIt, class UnaryFunc>
class mapped_iterator : public RootIt {
UnaryFunc Fn;
public:
typedef typename UnaryFunc::result_type value_type;
typedef typename UnaryFunc::result_type *pointer;
typedef void reference; // Can't modify value returned by fn
typedef mapped_iterator<RootIt, UnaryFunc> _Self;
typedef RootIt super;
inline explicit mapped_iterator(const RootIt &I) : super(I) {}
inline mapped_iterator(const super &It) : super(It) {}
inline value_type operator*() const { // All this work to do
return Fn(super::operator*()); // this little thing
}
};
#endif
// map_iterator - Provide a convenient way to create mapped_iterators, just like
// make_pair is useful for creating pairs...
@@ -138,43 +163,6 @@ inline mapped_iterator<ItTy, FuncTy> map_iterator(const ItTy &I, FuncTy F) {
}
// next/prior - These functions unlike std::advance do not modify the
// passed iterator but return a copy.
//
// next(myIt) returns copy of myIt incremented once
// next(myIt, n) returns copy of myIt incremented n times
// prior(myIt) returns copy of myIt decremented once
// prior(myIt, n) returns copy of myIt decremented n times
template <typename ItTy, typename Dist>
inline ItTy next(ItTy it, Dist n)
{
std::advance(it, n);
return it;
}
template <typename ItTy>
inline ItTy next(ItTy it)
{
std::advance(it, 1);
return it;
}
template <typename ItTy, typename Dist>
inline ItTy prior(ItTy it, Dist n)
{
std::advance(it, -n);
return it;
}
template <typename ItTy>
inline ItTy prior(ItTy it)
{
std::advance(it, -1);
return it;
}
//===----------------------------------------------------------------------===//
// Extra additions to <algorithm>
//===----------------------------------------------------------------------===//

View File

@@ -19,14 +19,11 @@
namespace llvm {
/// RemoveFileOnSignal - This function registers signal handlers to ensure
/// that if a signal gets delivered that the named file is removed.
///
void RemoveFileOnSignal(const std::string &Filename);
// RemoveFileOnSignal - This function registers signal handlers to ensure that
// if a signal gets delivered that the named file is removed.
//
void RemoveFileOnSignal(const std::string &Filename);
/// PrintStackTraceOnErrorSignal - When an error signal (such as SIBABRT or
/// SIGSEGV) is delivered to the process, print a stack trace and then exit.
void PrintStackTraceOnErrorSignal();
} // End llvm namespace
#endif

View File

@@ -1,65 +0,0 @@
//===- SlowOperationInformer.h - Keep the user informed ---------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file was developed by the LLVM research group and is distributed under
// the University of Illinois Open Source License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This file defines a simple object which can be used to let the user know what
// is going on when a slow operation is happening, and gives them the ability to
// cancel it. Potentially slow operations can stack allocate one of these
// objects, and periodically call the "progress" method to update the progress
// bar. If the operation takes more than 1 second to complete, the progress bar
// is automatically shown and updated. As such, the slow operation should not
// print stuff to the screen, and should not be confused if an extra line
// appears on the screen (ie, the cursor should be at the start of the line).
//
// If the user presses CTRL-C during the operation, the next invocation of the
// progress method with throw an std::string object indicating that the
// operation was cancelled. As such, client code must be exception safe around
// the progress method.
//
// Because SlowOperationInformers fiddle around with signals, they cannot be
// nested, and interact poorly with threads. The SIGALRM handler is set back to
// SIGDFL, but the SIGINT signal handler is restored when the
// SlowOperationInformer is destroyed.
//
//===----------------------------------------------------------------------===//
#ifndef SUPPORT_SLOW_OPERATION_INFORMER_H
#define SUPPORT_SLOW_OPERATION_INFORMER_H
#include <string>
#include <cassert>
namespace llvm {
class SlowOperationInformer {
std::string OperationName;
unsigned LastPrintAmount;
SlowOperationInformer(const SlowOperationInformer&); // DO NOT IMPLEMENT
void operator=(const SlowOperationInformer&); // DO NOT IMPLEMENT
public:
SlowOperationInformer(const std::string &Name);
~SlowOperationInformer();
/// progress - Clients should periodically call this method when they are in
/// an exception-safe state. The Amount variable should indicate how far
/// along the operation is, given in 1/10ths of a percent (in other words,
/// Amount should range from 0 to 1000).
void progress(unsigned Amount);
/// progress - Same as the method above, but this performs the division for
/// you, and helps you avoid overflow if you are dealing with largish
/// numbers.
void progress(unsigned Current, unsigned Maximum) {
assert(Maximum != 0 &&
"Shouldn't be doing work if there is nothing to do!");
progress(Current*1000ULL/Maximum);
}
};
} // end namespace llvm
#endif /* SLOW_OPERATION_INFORMER_H */

View File

@@ -15,9 +15,9 @@
// This is useful for reporting information like the number of instructions
// simplified, optimized or removed by various transformations, like this:
//
// static Statistic<> NumInstsKilled("gcse", "Number of instructions killed");
// static Statistic<> NumInstEliminated("GCSE - Number of instructions killed");
//
// Later, in the code: ++NumInstsKilled;
// Later, in the code: ++NumInstEliminated;
//
//===----------------------------------------------------------------------===//
@@ -76,8 +76,6 @@ public:
const Statistic &operator=(DataType Val) { Value = Val; return *this; }
const Statistic &operator++() { ++Value; return *this; }
DataType operator++(int) { return Value++; }
const Statistic &operator--() { --Value; return *this; }
DataType operator--(int) { return Value--; }
const Statistic &operator+=(const DataType &V) { Value += V; return *this; }
const Statistic &operator-=(const DataType &V) { Value -= V; return *this; }
};

View File

@@ -97,16 +97,6 @@ static inline std::string ftostr(double V) {
return Buffer;
}
/// getToken - This function extracts one token from source, ignoring any
/// leading characters that appear in the Delimiters string, and ending the
/// token at any of the characters that appear in the Delimiters string. If
/// there are no tokens in the source string, an empty string is returned.
/// The Source source string is updated in place to remove the returned string
/// and any delimiter prefix from it.
std::string getToken(std::string &Source,
const char *Delimiters = " \t\n\v\f\r");
} // End llvm namespace
#endif

View File

@@ -1,34 +0,0 @@
//===-- Support/ThreadSupport-NoSupport.h - Generic impl --------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file was developed by the LLVM research group and is distributed under
// the University of Illinois Open Source License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This file defines a generic ThreadSupport implementation used when there is
// no supported threading mechanism on the current system. Users should never
// #include this file directly!
//
//===----------------------------------------------------------------------===//
// Users should never #include this file directly! As such, no include guards
// are needed.
#ifndef SUPPORT_THREADSUPPORT_H
#error "Code should not #include Support/ThreadSupport-NoSupport.h directly!"
#endif
namespace llvm {
/// Mutex - This class allows user code to protect variables shared between
/// threads. It implements a "recursive" mutex, to simplify user code.
///
/// Since there is no platform support for _creating threads_, the non-thread
/// implementation of this class is a noop.
///
struct Mutex {
void acquire () {}
void release () {}
};
}

View File

@@ -1,42 +0,0 @@
//===-- Support/ThreadSupport-PThreads.h - PThreads support -----*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file was developed by the LLVM research group and is distributed under
// the University of Illinois Open Source License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This file defines pthreads implementations of the generic threading
// mechanisms. Users should never #include this file directly!
//
//===----------------------------------------------------------------------===//
// Users should never #include this file directly! As such, no include guards
// are needed.
#ifndef SUPPORT_THREADSUPPORT_H
#error "Code should not #include Support/ThreadSupport/PThreads.h directly!"
#endif
#include <pthread.h>
namespace llvm {
/// Mutex - This class allows user code to protect variables shared between
/// threads. It implements a "recursive" mutex, to simplify user code.
///
class Mutex {
pthread_mutex_t mutex;
Mutex(const Mutex &); // DO NOT IMPLEMENT
void operator=(const Mutex &); // DO NOT IMPLEMENT
public:
Mutex() {
pthread_mutexattr_t Attr;
pthread_mutex_init(&mutex, &Attr);
}
~Mutex() { pthread_mutex_destroy(&mutex); }
void acquire () { pthread_mutex_lock (&mutex); }
void release () { pthread_mutex_unlock (&mutex); }
};
} // end namespace llvm

View File

@@ -1,40 +0,0 @@
//===-- Support/ThreadSupport.h - Generic threading support -----*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file was developed by the LLVM research group and is distributed under
// the University of Illinois Open Source License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This file defines platform-agnostic interfaces that can be used to write
// multi-threaded programs. Autoconf is used to chose the correct
// implementation of these interfaces, or default to a non-thread-capable system
// if no matching system support is available.
//
//===----------------------------------------------------------------------===//
#ifndef SUPPORT_THREADSUPPORT_H
#define SUPPORT_THREADSUPPORT_H
#if @HAVE_PTHREAD_MUTEX_LOCK@
#include "Support/ThreadSupport-PThreads.h"
#else
#include "Support/ThreadSupport-NoSupport.h"
#endif // If no system support is available
namespace llvm {
/// MutexLocker - Instances of this class acquire a given Lock when
/// constructed and hold that lock until destruction.
///
class MutexLocker {
Mutex &M;
MutexLocker(const MutexLocker &); // DO NOT IMPLEMENT
void operator=(const MutexLocker &); // DO NOT IMPLEMENT
public:
MutexLocker(Mutex &m) : M(m) { M.acquire(); }
~MutexLocker() { M.release(); }
};
}
#endif // SUPPORT_THREADSUPPORT_H

View File

@@ -25,7 +25,9 @@
// 3.1 __gnu_cxx ext/hash_map
//
#if @HAVE_GNU_EXT_HASH_MAP@
#include "Config/config.h"
#ifdef HAVE_GNU_EXT_HASH_MAP
// This is for GCC-3.1+ which puts hash in ext/hash_map
# include <ext/hash_map>
# ifndef HASH_NAMESPACE
@@ -33,7 +35,7 @@
# endif
// GCC 3.0.x puts hash_map in <ext/hash_map> and in the std namespace.
#elif @HAVE_STD_EXT_HASH_MAP@
#elif defined(HAVE_STD_EXT_HASH_MAP)
# include <ext/hash_map>
# ifndef HASH_NAMESPACE
# define HASH_NAMESPACE std
@@ -41,7 +43,7 @@
// Older compilers such as GCC before version 3.0 do not keep
// extensions in the `ext' directory, and ignore the `std' namespace.
#elif @HAVE_GLOBAL_HASH_MAP@
#elif defined(HAVE_GLOBAL_HASH_MAP)
# include <hash_map>
# ifndef HASH_NAMESPACE
# define HASH_NAMESPACE std

View File

@@ -26,16 +26,18 @@
// 3.1 __gnu_cxx ext/hash_set
//
#include "Config/config.h"
// GCC versions 3.1 and later put hash_set in <ext/hash_set> and in
// the __gnu_cxx namespace.
#if @HAVE_GNU_EXT_HASH_SET@
#if defined(HAVE_GNU_EXT_HASH_SET)
# include <ext/hash_set>
# ifndef HASH_NAMESPACE
# define HASH_NAMESPACE __gnu_cxx
# endif
// GCC 3.0.x puts hash_set in <ext/hash_set> and in the std namespace.
#elif @HAVE_STD_EXT_HASH_SET@
#elif defined(HAVE_STD_EXT_HASH_SET)
# include <ext/hash_set>
# ifndef HASH_NAMESPACE
# define HASH_NAMESPACE std
@@ -43,7 +45,7 @@
// Older compilers such as GCC before version 3.0 do not keep
// extensions in the `ext' directory, and ignore the `std' namespace.
#elif @HAVE_GLOBAL_HASH_SET@
#elif defined(HAVE_GLOBAL_HASH_SET)
# include <hash_set>
# ifndef HASH_NAMESPACE
# define HASH_NAMESPACE std

View File

@@ -152,109 +152,15 @@ public:
return tmp;
}
// Internal interface, do not use...
pointer getNodePtrUnchecked() const { return NodePtr; }
};
// do not implement. this is to catch errors when people try to use
// them as random access iterators
template<typename T>
void operator-(int, ilist_iterator<T>);
template<typename T>
void operator-(ilist_iterator<T>,int);
template<typename T>
void operator+(int, ilist_iterator<T>);
template<typename T>
void operator+(ilist_iterator<T>,int);
//===----------------------------------------------------------------------===//
// ilist_compat_iterator<Node> - Compatibility iterator for intrusive list.
// This makes an ilist<X> act like an std::list<X*>, where you have to
// dereference stuff multiple times. This should only be used for temporary
// migration purposes. Because we don't support "changing the pointer", we only
// expose constant pointers.
//
template<typename NodeTy>
class ilist_compat_iterator
: public bidirectional_iterator<NodeTy* const, ptrdiff_t> {
typedef ilist_traits<NodeTy> Traits;
typedef bidirectional_iterator<NodeTy* const, ptrdiff_t> super;
public:
typedef size_t size_type;
typedef typename super::pointer pointer;
typedef typename super::reference reference;
private:
NodeTy *NodePtr;
public:
ilist_compat_iterator(NodeTy *NP) : NodePtr(NP) {}
ilist_compat_iterator() : NodePtr(0) {}
// This is templated so that we can allow constructing a const iterator from
// a nonconst iterator...
template<class node_ty>
ilist_compat_iterator(const ilist_compat_iterator<node_ty> &RHS)
: NodePtr(RHS.getNodePtrUnchecked()) {}
// This is templated so that we can allow assigning to a const iterator from
// a nonconst iterator...
template<class node_ty>
const ilist_compat_iterator &operator=(const
ilist_compat_iterator<node_ty> &RHS) {
NodePtr = RHS.getNodePtrUnchecked();
return *this;
}
// Accessors...
operator pointer() const {
assert(Traits::getNext(NodePtr) != 0 && "Dereferencing end()!");
return &NodePtr;
}
reference operator*() const {
assert(Traits::getNext(NodePtr) != 0 && "Dereferencing end()!");
return NodePtr;
}
pointer operator->() { return &operator*(); }
const pointer operator->() const { return &operator*(); }
// Comparison operators
bool operator==(const ilist_compat_iterator &RHS) const {
return NodePtr == RHS.NodePtr;
}
bool operator!=(const ilist_compat_iterator &RHS) const {
return NodePtr != RHS.NodePtr;
}
// Increment and decrement operators...
ilist_compat_iterator &operator--() { // predecrement - Back up
NodePtr = Traits::getPrev(NodePtr);
assert(NodePtr && "--'d off the beginning of an ilist!");
return *this;
}
ilist_compat_iterator &operator++() { // preincrement - Advance
NodePtr = Traits::getNext(NodePtr);
assert(NodePtr && "++'d off the end of an ilist!");
return *this;
}
ilist_compat_iterator operator--(int) { // postdecrement operators...
ilist_compat_iterator tmp = *this;
--*this;
return tmp;
}
ilist_compat_iterator operator++(int) { // postincrement operators...
ilist_compat_iterator tmp = *this;
++*this;
return tmp;
}
// Dummy operators to make errors apparent...
template<class X> void operator+(X Val) {}
template<class X> void operator-(X Val) {}
// Internal interface, do not use...
pointer getNodePtrUnchecked() const { return NodePtr; }
};
// Allow ilist_iterators to convert into pointers to a node automatically when
// used by the dyn_cast, cast, isa mechanisms...
@@ -307,25 +213,19 @@ public:
}
~iplist() { clear(); delete Tail; }
// Iterator creation methods.
// Iterator creation methods...
iterator begin() { return iterator(Head); }
const_iterator begin() const { return const_iterator(Head); }
iterator end() { return iterator(Tail); }
const_iterator end() const { return const_iterator(Tail); }
// reverse iterator creation methods.
// reverse iterator creation methods...
reverse_iterator rbegin() { return reverse_iterator(end()); }
const_reverse_iterator rbegin() const{ return const_reverse_iterator(end()); }
reverse_iterator rend() { return reverse_iterator(begin()); }
const_reverse_iterator rend() const {return const_reverse_iterator(begin());}
// "compatibility" iterator creation methods.
typedef ilist_compat_iterator<NodeTy> compat_iterator;
compat_iterator compat_begin() const { return compat_iterator(Head); }
compat_iterator compat_end() const { return compat_iterator(Tail); }
// Miscellaneous inspection routines.
// Miscellaneous inspection routines...
size_type max_size() const { return size_type(-1); }
bool empty() const { return Head == Tail; }

View File

@@ -21,46 +21,56 @@
// 1. bidirectional_iterator
// 2. forward_iterator
//
// The #if directives' expressions are filled in by Autoconf.
//
//===----------------------------------------------------------------------===//
#ifndef SUPPORT_ITERATOR
#define SUPPORT_ITERATOR
#include "Config/config.h"
#include <iterator>
#if !@HAVE_BI_ITERATOR@
# if @HAVE_STD_ITERATOR@
/// If the bidirectional iterator is not defined, we attempt to define it in
/// terms of the C++ standard iterator. Otherwise, we import it with a "using"
/// statement.
///
//////////////////////////////////////////////////////////////////////////////
// If the bidirectional iterator is not defined, attempt to define it using
// the C++ standard iterator.
//////////////////////////////////////////////////////////////////////////////
#ifndef HAVE_BI_ITERATOR
#ifdef HAVE_STD_ITERATOR
// Define stupid wrappers around std::iterator...
template<class Ty, class PtrDiffTy>
struct bidirectional_iterator
: public std::iterator<std::bidirectional_iterator_tag, Ty, PtrDiffTy> {
};
# else
# error "Need to have standard iterator to define bidirectional iterator!"
# endif
#else
using std::bidirectional_iterator;
#error "Need to have standard iterator to define bidirectional iterator!"
#endif
#if !@HAVE_FWD_ITERATOR@
# if @HAVE_STD_ITERATOR@
/// If the forward iterator is not defined, attempt to define it in terms of
/// the C++ standard iterator. Otherwise, we import it with a "using" statement.
///
#else
// Just use bidirectional_iterator directly.
using std::bidirectional_iterator;
#endif
//////////////////////////////////////////////////////////////////////////////
// If the forward iterator is not defined, attempt to define it using the
// C++ standard iterator.
//////////////////////////////////////////////////////////////////////////////
#ifndef HAVE_FWD_ITERATOR
#ifdef HAVE_STD_ITERATOR
template<class Ty, class PtrDiffTy>
struct forward_iterator
: public std::iterator<std::forward_iterator_tag, Ty, PtrDiffTy> {
};
# else
# error "Need to have standard iterator to define forward iterator!"
# endif
#else
#error "Need to have standard iterator to define forward iterator!"
#endif
#else
// Just use forward iterator directly.
using std::forward_iterator;
#endif
#endif

View File

@@ -0,0 +1,44 @@
//===-- Support/slist - "Portable" wrapper around slist ---------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file was developed by the LLVM research group and is distributed under
// the University of Illinois Open Source License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This file provides a wrapper around the mysterious <slist> header file that
// seems to move around between GCC releases into and out of namespaces at will.
// #including this header will cause hash_map to be available in the global
// namespace.
//
//===----------------------------------------------------------------------===//
#ifndef SUPPORT_SLIST
#define SUPPORT_SLIST
#include "Config/config.h"
// Compiler Support Matrix
//
// Version Namespace Header File
// 2.95.x :: slist
// 3.0.4 std ext/slist
// 3.1 __gnu_cxx ext/slist
//
#ifdef HAVE_EXT_SLIST
#include <ext/slist>
#else
#include <slist>
#endif
#if HAVE_EXT_SLIST == std
using std::slist;
#endif
#if HAVE_EXT_SLIST == gnu
using __gnu_cxx::slist;
#endif
#endif

View File

@@ -1,54 +0,0 @@
//===- Support/type_traits.h - Simplfied type traits ------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file was developed by the LLVM research group and is distributed under
// the University of Illinois Open Source License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This file provides a template class that determines if a type is a class or
// not. The basic mechanism, based on using the pointer to member function of
// a zero argument to a function was "boosted" from the boost type_traits
// library. See http://www.boost.org/ for all the gory details.
//
//===----------------------------------------------------------------------===//
#ifndef LLVM_SUPPORT_TYPE_TRAITS_H
#define LLVM_SUPPORT_TYPE_TRAITS_H
// This is actually the conforming implementation which works with abstract
// classes. However, enough compilers have trouble with it that most will use
// the one in boost/type_traits/object_traits.hpp. This implementation actually
// works with VC7.0, but other interactions seem to fail when we use it.
namespace llvm {
namespace dont_use
{
// These two functions should never be used. They are helpers to
// the is_class template below. They cannot be located inside
// is_class because doing so causes at least GCC to think that
// the value of the "value" enumerator is not constant. Placing
// them out here (for some strange reason) allows the sizeof
// operator against them to magically be constant. This is
// important to make the is_class<T>::value idiom zero cost. it
// evaluates to a constant 1 or 0 depending on whether the
// parameter T is a class or not (respectively).
template<typename T> char is_class_helper(void(T::*)(void));
template<typename T> double is_class_helper(...);
}
template <typename T>
struct is_class
{
// is_class<> metafunction due to Paul Mensonides (leavings@attbi.com). For
// more details:
// http://groups.google.com/groups?hl=en&selm=000001c1cc83%24e154d5e0%247772e50c%40c161550a&rnum=1
public:
enum { value = sizeof(char) == sizeof(dont_use::is_class_helper<T>(0)) };
};
}
#endif

View File

@@ -0,0 +1,6 @@
Boost
------------------------------------------------------------------------------
The boost header files are licensed under the LLVM license. They also have
additional copyrights that can be found in each individual source file in
llvm/include/boost.

View File

@@ -0,0 +1,5 @@
These files were taken from boost 1.28.0.
See http://www.boost.org for more information.

View File

@@ -0,0 +1,69 @@
// Boost config.hpp configuration header file ------------------------------//
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
// Boost config.hpp policy and rationale documentation has been moved to
// http://www.boost.org/libs/config
//
// CAUTION: This file is intended to be completely stable -
// DO NOT MODIFY THIS FILE!
//
#ifndef BOOST_CONFIG_HPP
#define BOOST_CONFIG_HPP
// if we don't have a user config, then use the default location:
#if !defined(BOOST_USER_CONFIG) && !defined(BOOST_NO_USER_CONFIG)
# define BOOST_USER_CONFIG <boost/config/user.hpp>
#endif
// include it first:
#ifdef BOOST_USER_CONFIG
# include BOOST_USER_CONFIG
#endif
// if we don't have a compiler config set, try and find one:
#if !defined(BOOST_COMPILER_CONFIG) && !defined(BOOST_NO_COMPILER_CONFIG) && !defined(BOOST_NO_CONFIG)
# include <boost/config/select_compiler_config.hpp>
#endif
// if we have a compiler config, include it now:
#ifdef BOOST_COMPILER_CONFIG
# include BOOST_COMPILER_CONFIG
#endif
// if we don't have a std library config set, try and find one:
#if !defined(BOOST_STDLIB_CONFIG) && !defined(BOOST_NO_STDLIB_CONFIG) && !defined(BOOST_NO_CONFIG)
# include <boost/config/select_stdlib_config.hpp>
#endif
// if we have a std library config, include it now:
#ifdef BOOST_STDLIB_CONFIG
# include BOOST_STDLIB_CONFIG
#endif
// if we don't have a platform config set, try and find one:
#if !defined(BOOST_PLATFORM_CONFIG) && !defined(BOOST_NO_PLATFORM_CONFIG) && !defined(BOOST_NO_CONFIG)
# include <boost/config/select_platform_config.hpp>
#endif
// if we have a platform config, include it now:
#ifdef BOOST_PLATFORM_CONFIG
# include BOOST_PLATFORM_CONFIG
#endif
// get config suffix code:
#include <boost/config/suffix.hpp>
#endif // BOOST_CONFIG_HPP

View File

@@ -0,0 +1,83 @@
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
// Borland C++ compiler setup:
// Version 5.0 and below:
# if __BORLANDC__ <= 0x0550
// Borland C++Builder 4 and 5:
# define BOOST_NO_MEMBER_TEMPLATE_FRIENDS
# if __BORLANDC__ == 0x0550
// Borland C++Builder 5, command-line compiler 5.5:
# define BOOST_NO_OPERATORS_IN_NAMESPACE
# endif
# endif
// Version 5.51 and below:
#if (__BORLANDC__ <= 0x551)
# define BOOST_NO_CV_SPECIALIZATIONS
# define BOOST_NO_CV_VOID_SPECIALIZATIONS
# define BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS
#endif
// Version 6.0 and below:
#if (__BORLANDC__ <= 0x560) || !defined(BOOST_STRICT_CONFIG)
# define BOOST_NO_DEPENDENT_NESTED_DERIVATIONS
# define BOOST_NO_INTEGRAL_INT64_T
# define BOOST_NO_PRIVATE_IN_AGGREGATE
# define BOOST_NO_SWPRINTF
# define BOOST_NO_USING_TEMPLATE
// we shouldn't really need this - but too many things choke
// without it, this needs more investigation:
# define BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS
#endif
// Borland C++Builder 6 defaults to using STLPort. If _USE_OLD_RW_STL is
// defined, then we have 0x560 or greater with the Rogue Wave implementation
// which presumably has the std::DBL_MAX bug.
#if ((__BORLANDC__ >= 0x550) && (__BORLANDC__ < 0x560)) || defined(_USE_OLD_RW_STL)
// <climits> is partly broken, some macros define symbols that are really in
// namespace std, so you end up having to use illegal constructs like
// std::DBL_MAX, as a fix we'll just include float.h and have done with:
#include <float.h>
#endif
//
// __int64:
//
#if __BORLANDC__ >= 0x530
# define BOOST_HAS_MS_INT64
#endif
//
// check for exception handling support:
//
#ifndef _CPPUNWIND
# define BOOST_NO_EXCEPTIONS
#endif
//
// Disable Win32 support in ANSI mode:
//
#pragma defineonoption BOOST_DISABLE_WIN32 -A
#define BOOST_COMPILER "Borland C++ version " BOOST_STRINGIZE(__BORLANDC__)
//
// versions check:
// we don't support Borland prior to version 5.4:
#if __BORLANDC__ < 0x540
# error "Compiler not supported or configured - please reconfigure"
#endif
//
// last known and checked version is 5.6:
#if (__BORLANDC__ > 0x560)
# if defined(BOOST_ASSERT_CONFIG)
# error "Unknown compiler version - please run the configure tests and report the results"
# else
# pragma message( "Unknown compiler version - please run the configure tests and report the results")
# endif
#endif

View File

@@ -0,0 +1,65 @@
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
// Comeau C++ compiler setup:
#include "boost/config/compiler/common_edg.hpp"
#if (__COMO_VERSION__ <= 4245) || !defined(BOOST_STRICT_CONFIG)
# if defined(_MSC_VER) && _MSC_VER <= 1300
# define BOOST_NO_STDC_NAMESPACE
# define BOOST_NO_SWPRINTF
# if _MSC_VER > 100
// only set this in non-strict mode:
# define BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP
# endif
# endif
// Void returns don't work when emulating VC 6 (Peter Dimov)
# if defined(_MSC_VER) && (_MSC_VER == 1200)
# define BOOST_NO_VOID_RETURNS
# endif
#endif // version 4245
//
// enable __int64 support in VC emulation mode
// we should also set BOOST_HAS_LONG_LONG when that is
// supported, but there is no way we can detect it:
//
# if defined(_MSC_VER) && (_MSC_VER >= 1200)
# define BOOST_HAS_MS_INT64
# endif
//
// disable win32 support unless we are in VC emulation mode,
// (what does this do to Como on top of Borland?):
//
#if defined(_WIN32) && (_MSC_VER+0 < 1000)
# define BOOST_DISABLE_WIN32
#endif
#define BOOST_COMPILER "Comeau compiler version " BOOST_STRINGIZE(__COMO_VERSION__)
//
// versions check:
// we don't know Comeau prior to version 4245:
#if __COMO_VERSION__ < 4245
# error "Compiler not configured - please reconfigure"
#endif
//
// last known and checked version is 4245:
#if (__COMO_VERSION__ > 4245)
# if defined(BOOST_ASSERT_CONFIG)
# error "Unknown compiler version - please run the configure tests and report the results"
# endif
#endif

View File

@@ -0,0 +1,34 @@
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
//
// Options common to all edg based compilers.
//
// This is included from within the individual compiler mini-configs.
#ifndef __EDG_VERSION__
# error This file requires that __EDG_VERSION__ be defined.
#endif
#if (__EDG_VERSION__ <= 238)
# define BOOST_NO_INTEGRAL_INT64_T
#endif
#if (__EDG_VERSION__ <= 240)
# define BOOST_NO_VOID_RETURNS
#endif
#if (__EDG_VERSION__ <= 241) && !defined(BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP)
# define BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP
#endif
#ifdef c_plusplus
// EDG has "long long" in non-strict mode
// However, some libraries have insufficient "long long" support
// #define BOOST_HAS_LONG_LONG
#endif

View File

@@ -0,0 +1,18 @@
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
// Dec Alpha True64 C++ compiler setup:
#define BOOST_COMPILER "Dec Alpha True64 " BOOST_STRINGIZE(__DECCXX_VER)
#include "boost/config/compiler/common_edg.hpp"
//
// versions check:
// Nothing to do here?

View File

@@ -0,0 +1,59 @@
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
// GNU C++ compiler setup:
# if __GNUC__ == 2 && __GNUC_MINOR__ == 91
// egcs 1.1 won't parse shared_ptr.hpp without this:
# define BOOST_NO_AUTO_PTR
# endif
# if __GNUC__ == 2 && __GNUC_MINOR__ < 95
//
// Prior to gcc 2.95 member templates only partly
// work - define BOOST_MSVC6_MEMBER_TEMPLATES
// instead since inline member templates mostly work.
//
# define BOOST_NO_MEMBER_TEMPLATES
# if __GNUC_MINOR__ >= 9
# define BOOST_MSVC6_MEMBER_TEMPLATES
# endif
# endif
# if __GNUC__ == 2 && __GNUC_MINOR__ <= 97
# define BOOST_NO_MEMBER_TEMPLATE_FRIENDS
# define BOOST_NO_OPERATORS_IN_NAMESPACE
# endif
//
// Threading support:
// Turn this on unconditionally here, it will get turned off again later
// if no threading API is detected.
//
#define BOOST_HAS_THREADS
//
// gcc has "long long"
//
#define BOOST_HAS_LONG_LONG
#define BOOST_COMPILER "GNU C++ version " BOOST_STRINGIZE(__GNUC__) "." BOOST_STRINGIZE(__GNUC_MINOR__)
//
// versions check:
// we don't know gcc prior to version 2.90:
#if (__GNUC__ == 2) && (__GNUC_MINOR__ < 90)
# error "Compiler not configured - please reconfigure"
#endif
//
// last known and checked version is 3.4:
#if (__GNUC__ > 3) || ((__GNUC__ == 3) && (__GNUC_MINOR__ > 4))
# if defined(BOOST_ASSERT_CONFIG)
# error "Unknown compiler version - please run the configure tests and report the results"
# else
# warning "Unknown compiler version - please run the configure tests and report the results"
# endif
#endif

View File

@@ -0,0 +1,27 @@
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
// Greenhills C++ compiler setup:
#define BOOST_COMPILER "Greenhills C++ version " BOOST_STRINGIZE(__ghs)
#include "boost/config/compiler/common_edg.hpp"
//
// versions check:
// we don't support Greenhills prior to version 0:
#if __ghs < 0
# error "Compiler not supported or configured - please reconfigure"
#endif
//
// last known and checked version is 0:
#if (__ghs > 0)
# if defined(BOOST_ASSERT_CONFIG)
# error "Unknown compiler version - please run the configure tests and report the results"
# endif
#endif

View File

@@ -0,0 +1,41 @@
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
// HP aCC C++ compiler setup:
#if (__HP_aCC <= 33100)
# define BOOST_NO_INTEGRAL_INT64_T
# define BOOST_NO_OPERATORS_IN_NAMESPACE
# if !defined(_NAMESPACE_STD)
# define BOOST_NO_STD_LOCALE
# define BOOST_NO_STRINGSTREAM
# endif
#endif
#if (__HP_aCC <= 33300) || !defined(BOOST_STRICT_CONFIG)
// member templates are sufficiently broken that we disable them for now
# define BOOST_NO_MEMBER_TEMPLATES
# define BOOST_NO_DEPENDENT_NESTED_DERIVATIONS
# define BOOST_NO_DEPENDENT_TYPES_IN_TEMPLATE_VALUE_PARAMETERS
#endif
#define BOOST_COMPILER "HP aCC version " BOOST_STRINGIZE(__HP_aCC)
//
// versions check:
// we don't support HP aCC prior to version 0:
#if __HP_aCC < 33000
# error "Compiler not supported or configured - please reconfigure"
#endif
//
// last known and checked version is 0:
#if (__HP_aCC > 33300)
# if defined(BOOST_ASSERT_CONFIG)
# error "Unknown compiler version - please run the configure tests and report the results"
# endif
#endif

View File

@@ -0,0 +1,82 @@
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
// Intel compiler setup:
#include "boost/config/compiler/common_edg.hpp"
#ifdef __ICL
# define BOOST_COMPILER "Intel C++ version " BOOST_STRINGIZE(__ICL)
# define BOOST_INTEL_CXX_VERSION __ICL
#else
# define BOOST_COMPILER "Intel C++ version " BOOST_STRINGIZE(__ICC)
# define BOOST_INTEL_CXX_VERSION __ICC
#endif
#if (BOOST_INTEL_CXX_VERSION <= 500) && defined(_MSC_VER)
# define BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS
#endif
#if (BOOST_INTEL_CXX_VERSION <= 600) || !defined(BOOST_STRICT_CONFIG)
# if defined(_MSC_VER) && (_MSC_VER <= 1300) // added check for <= VC 7 (Peter Dimov)
// Intel C++ 5.0.1 uses EDG 2.45, but fails to activate Koenig lookup
// in the frontend even in "strict" mode, unless you use
// -Qoption,cpp,--arg_dep_lookup. (reported by Kirk Klobe & Thomas Witt)
// Similarly, -Qoption,cpp,--new_for_init enables new-style "for" loop
// variable scoping. (reported by Thomas Witt)
// Intel C++ 6.0 (currently in Beta test) doesn't have any front-end
// changes at all. (reported by Kirk Klobe)
# ifndef BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP
# define BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP
# endif
# define BOOST_NO_SWPRINTF
# define BOOST_NO_INCLASS_MEMBER_INITIALIZATION
# endif
// Void returns, 64 bit integrals don't work when emulating VC 6 (Peter Dimov)
# if defined(_MSC_VER) && (_MSC_VER <= 1200)
# define BOOST_NO_VOID_RETURNS
# define BOOST_NO_INTEGRAL_INT64_T
# endif
#endif
#if _MSC_VER+0 >= 1000
# ifndef _NATIVE_WCHAR_T_DEFINED
# define BOOST_NO_INTRINSIC_WCHAR_T
# endif
# if _MSC_VER >= 1200
# define BOOST_HAS_MS_INT64
# endif
# define BOOST_NO_SWPRINTF
#elif defined(_WIN32)
# define BOOST_DISABLE_WIN32
#endif
//
// versions check:
// we don't support Intel prior to version 5.0:
#if BOOST_INTEL_CXX_VERSION < 500
# error "Compiler not supported or configured - please reconfigure"
#endif
//
// last known and checked version is 600:
#if (BOOST_INTEL_CXX_VERSION > 600)
# if defined(BOOST_ASSERT_CONFIG)
# error "Unknown compiler version - please run the configure tests and report the results"
# elif defined(_MSC_VER)
# pragma message("Unknown compiler version - please run the configure tests and report the results")
# endif
#endif

View File

@@ -0,0 +1,27 @@
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
// Kai C++ compiler setup:
#include "boost/config/compiler/common_edg.hpp"
# if (__KCC_VERSION <= 4001) || !defined(BOOST_STRICT_CONFIG)
// at least on Sun, the contents of <cwchar> is not in namespace std
# define BOOST_NO_STDC_NAMESPACE
# endif
#define BOOST_COMPILER "Kai C++ version " BOOST_STRINGIZE(__KCC_VERSION)
//
// last known and checked version is 4001:
#if (__KCC_VERSION > 4001)
# if defined(BOOST_ASSERT_CONFIG)
# error "Unknown compiler version - please run the configure tests and report the results"
# endif
#endif

View File

@@ -0,0 +1,55 @@
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
// Metrowerks C++ compiler setup:
// locale support is disabled when linking with the dynamic runtime
# ifdef _MSL_NO_LOCALE
# define BOOST_NO_STD_LOCALE
# endif
# if __MWERKS__ <= 0x2301 // 5.3
# define BOOST_NO_FUNCTION_TEMPLATE_ORDERING
# define BOOST_NO_POINTER_TO_MEMBER_CONST
# define BOOST_NO_DEPENDENT_TYPES_IN_TEMPLATE_VALUE_PARAMETERS
# define BOOST_NO_MEMBER_TEMPLATE_KEYWORD
# endif
# if __MWERKS__ <= 0x2401 // 6.2
//# define BOOST_NO_FUNCTION_TEMPLATE_ORDERING
# endif
# if(__MWERKS__ <= 0x2406) || !defined(BOOST_STRICT_CONFIG) // 7.0 & 7.1
# define BOOST_NO_MEMBER_TEMPLATE_FRIENDS
# endif
#if !__option(wchar_type)
# define BOOST_NO_INTRINSIC_WCHAR_T
#endif
#define BOOST_COMPILER "Metrowerks CodeWarrior C++ version " BOOST_STRINGIZE(__MWERKS__)
//
// versions check:
// we don't support Metrowerks prior to version 5.3:
#if __MWERKS__ < 0x2301
# error "Compiler not supported or configured - please reconfigure"
#endif
//
// last known and checked version is 0x2406:
#if (__MWERKS__ > 0x2406)
# if defined(BOOST_ASSERT_CONFIG)
# error "Unknown compiler version - please run the configure tests and report the results"
# endif
#endif

View File

@@ -0,0 +1,49 @@
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
// MPW C++ compilers setup:
# if defined(__SC__)
# define BOOST_COMPILER "MPW SCpp version " BOOST_STRINGIZE(__SC__)
# elif defined(__MRC__)
# define BOOST_COMPILER "MPW MrCpp version " BOOST_STRINGIZE(__MRC__)
# else
# error "Using MPW compiler configuration by mistake. Please update."
# endif
//
// MPW 8.90:
//
#if (MPW_CPLUS <= 0x890) || !defined(BOOST_STRICT_CONFIG)
# define BOOST_NO_CV_SPECIALIZATIONS
# define BOOST_NO_DEPENDENT_NESTED_DERIVATIONS
# define BOOST_NO_DEPENDENT_TYPES_IN_TEMPLATE_VALUE_PARAMETERS
# define BOOST_NO_INCLASS_MEMBER_INITIALIZATION
# define BOOST_NO_INTRINSIC_WCHAR_T
# define BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
# define BOOST_NO_USING_TEMPLATE
# define BOOST_NO_CWCHAR
# define BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS
# define BOOST_NO_STD_ALLOCATOR /* actually a bug with const reference overloading */
#endif
//
// versions check:
// we don't support MPW prior to version 8.9:
#if MPW_CPLUS < 0x890
# error "Compiler not supported or configured - please reconfigure"
#endif
//
// last known and checked version is 0x890:
#if (MPW_CPLUS > 0x890)
# if defined(BOOST_ASSERT_CONFIG)
# error "Unknown compiler version - please run the configure tests and report the results"
# endif
#endif

View File

@@ -0,0 +1,23 @@
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
// SGI C++ compiler setup:
#define BOOST_COMPILER "SGI Irix compiler version " BOOST_STRINGIZE(_COMPILER_VERSION)
#include "boost/config/compiler/common_edg.hpp"
//
// Threading support:
// Turn this on unconditionally here, it will get turned off again later
// if no threading API is detected.
//
#define BOOST_HAS_THREADS
//
// version check:
// probably nothing to do here?

View File

@@ -0,0 +1,66 @@
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
// Sun C++ compiler setup:
# if __SUNPRO_CC <= 0x500
# define BOOST_NO_MEMBER_TEMPLATES
# define BOOST_NO_FUNCTION_TEMPLATE_ORDERING
# endif
# if (__SUNPRO_CC <= 0x520)
//
// Sunpro 5.2 and earler:
//
// although sunpro 5.2 supports the syntax for
// inline initialization it often gets the value
// wrong, especially where the value is computed
// from other constants (J Maddock 6th May 2001)
# define BOOST_NO_INCLASS_MEMBER_INITIALIZATION
// Although sunpro 5.2 supports the syntax for
// partial specialization, it often seems to
// bind to the wrong specialization. Better
// to disable it until suppport becomes more stable
// (J Maddock 6th May 2001).
# define BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
# endif
# if (__SUNPRO_CC <= 0x530) || !defined(BOOST_STRICT_CONFIG)
// SunPro 5.3 has better support for partial specialization,
// but breaks when compiling std::less<shared_ptr<T> >
// (Jens Maurer 4 Nov 2001).
// std::less specialization fixed as reported by George
// Heintzelman; partial specialization re-enabled
// (Peter Dimov 17 Jan 2002)
//# define BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
// integral constant expressions with 64 bit numbers fail
# define BOOST_NO_INTEGRAL_INT64_T
# endif
#define BOOST_COMPILER "Sun compiler version " BOOST_STRINGIZE(__SUNPRO_CC)
//
// versions check:
// we don't support sunpro prior to version 4:
#if __SUNPRO_CC < 0x400
#error "Compiler not supported or configured - please reconfigure"
#endif
//
// last known and checked version is 0x530:
#if (__SUNPRO_CC > 0x530)
# if defined(BOOST_ASSERT_CONFIG)
# error "Unknown compiler version - please run the configure tests and report the results"
# endif
#endif

View File

@@ -0,0 +1,36 @@
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
// Visual Age (IBM) C++ compiler setup:
#define BOOST_NO_MEMBER_TEMPLATE_FRIENDS
#define BOOST_NO_INCLASS_MEMBER_INITIALIZATION
//
// On AIX thread support seems to be indicated by _THREAD_SAFE:
//
#ifdef _THREAD_SAFE
# define BOOST_HAS_THREADS
#endif
#define BOOST_COMPILER "IBM Visual Age" BOOST_STRINGIZE(__IBMCPP__)
//
// versions check:
// we don't support Visual age prior to version 5:
#if __IBMCPP__ < 500
#error "Compiler not supported or configured - please reconfigure"
#endif
//
// last known and checked version is 500:
#if (__IBMCPP__ > 500)
# if defined(BOOST_ASSERT_CONFIG)
# error "Unknown compiler version - please run the configure tests and report the results"
# endif
#endif

View File

@@ -0,0 +1,111 @@
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
// Microsoft Visual C++ compiler setup:
#define BOOST_MSVC _MSC_VER
// turn off the warnings before we #include anything
#pragma warning( disable : 4503 ) // warning: decorated name length exceeded
#if _MSC_VER <= 1200 // 1200 == VC++ 6.0
#pragma warning( disable : 4786 ) // ident trunc to '255' chars in debug info
# define BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS
# define BOOST_NO_DEPENDENT_TYPES_IN_TEMPLATE_VALUE_PARAMETERS
# define BOOST_NO_VOID_RETURNS
// disable min/max macro defines on vc6:
//
# ifndef NOMINMAX
# define NOMINMAX
# endif
#endif
#if (_MSC_VER <= 1300) // || !defined(BOOST_STRICT_CONFIG) // VC7 Beta 2 or later
#if !defined(_MSC_EXTENSIONS) && !defined(BOOST_NO_DEPENDENT_TYPES_IN_TEMPLATE_VALUE_PARAMETERS) // VC7 bug with /Za
# define BOOST_NO_DEPENDENT_TYPES_IN_TEMPLATE_VALUE_PARAMETERS
#endif
# define BOOST_NO_INCLASS_MEMBER_INITIALIZATION
# define BOOST_NO_PRIVATE_IN_AGGREGATE
# define BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP
# define BOOST_NO_INTEGRAL_INT64_T
// VC++ 6/7 has member templates but they have numerous problems including
// cases of silent failure, so for safety we define:
# define BOOST_NO_MEMBER_TEMPLATES
// For VC++ experts wishing to attempt workarounds, we define:
# define BOOST_MSVC6_MEMBER_TEMPLATES
# define BOOST_NO_MEMBER_TEMPLATE_FRIENDS
# define BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
# define BOOST_NO_CV_VOID_SPECIALIZATIONS
# define BOOST_NO_FUNCTION_TEMPLATE_ORDERING
# define BOOST_NO_USING_TEMPLATE
# define BOOST_NO_SWPRINTF
//
// disable min/max macros if defined:
//
# ifdef min
# undef min
# endif
# ifdef max
# undef max
# endif
#endif
#if _MSC_VER <= 1301
# define BOOST_NO_SWPRINTF
#endif
#ifndef _NATIVE_WCHAR_T_DEFINED
# define BOOST_NO_INTRINSIC_WCHAR_T
#endif
//
// check for exception handling support:
#ifndef _CPPUNWIND
# define BOOST_NO_EXCEPTIONS
#endif
//
// __int64 support:
//
#if (_MSC_VER >= 1200) && defined(_MSC_EXTENSIONS)
# define BOOST_HAS_MS_INT64
#endif
//
// disable Win32 API's if compiler extentions are
// turned off:
//
#ifndef _MSC_EXTENSIONS
# define BOOST_DISABLE_WIN32
#endif
#define BOOST_COMPILER "Microsoft Visual C++ version " BOOST_STRINGIZE(_MSC_VER)
//
// versions check:
// we don't support Visual C++ prior to version 6:
#if _MSC_VER < 1200
#error "Compiler not supported or configured - please reconfigure"
#endif
//
// last known and checked version is 1301:
#if (_MSC_VER > 1301)
# if defined(BOOST_ASSERT_CONFIG)
# error "Unknown compiler version - please run the configure tests and report the results"
# else
# pragma message("Unknown compiler version - please run the configure tests and report the results")
# endif
#endif

View File

@@ -0,0 +1,24 @@
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
// IBM/Aix specific config options:
#define BOOST_PLATFORM "IBM Aix"
#define BOOST_HAS_UNISTD_H
#define BOOST_HAS_PTHREADS
#define BOOST_HAS_NL_TYPES_H
// Threading API's:
#define BOOST_HAS_PTHREAD_DELAY_NP
#define BOOST_HAS_PTHREAD_YIELD
// boilerplate code:
#include <boost/config/posix_features.hpp>

View File

@@ -0,0 +1,15 @@
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
#define BOOST_PLATFORM "AmigaOS"
#define BOOST_DISABLE_THREADS
#define BOOST_NO_CWCHAR
#define BOOST_NO_STD_WSTRING
#define BOOST_NO_INTRINSIC_WCHAR_T

View File

@@ -0,0 +1,25 @@
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
// BeOS specific config options:
#define BOOST_PLATFORM "BeOS"
#define BOOST_NO_CWCHAR
#define BOOST_NO_CWCTYPE
#define BOOST_HAS_UNISTD_H
#define BOOST_HAS_BETHREADS
#ifndef BOOST_DISABLE_THREADS
# define BOOST_HAS_THREADS
#endif
// boilerplate code:
#include <boost/config/posix_features.hpp>

View File

@@ -0,0 +1,61 @@
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
// generic BSD config options:
#if !defined(__FreeBSD__) && !defined(__NetBSD__) && !defined(__OpenBSD__)
#error "This platform is not BSD"
#endif
#ifdef __FreeBSD__
#define BOOST_PLATFORM "FreeBSD " BOOST_STRINGIZE(__FreeBSD__)
#elif defined(__NetBSD__)
#define BOOST_PLATFORM "NetBSD " BOOST_STRINGIZE(__NetBSD__)
#elif defined(__OpenBSD__)
#define BOOST_PLATFORM "OpenBSD " BOOST_STRINGIZE(__OpenBSD__)
#endif
//
// is this the correct version check?
// FreeBSD has <nl_types.h> but does not
// advertise the fact in <unistd.h>:
//
#if defined(__FreeBSD__) && (__FreeBSD__ >= 3)
# define BOOST_HAS_NL_TYPES_H
#endif
//
// FreeBSD 3.x has pthreads support, but defines _POSIX_THREADS in <pthread.h>
// and not in <unistd.h>
//
#if defined(__FreeBSD__) && (__FreeBSD__ <= 3)
# define BOOST_HAS_PTHREADS
#endif
//
// No wide character support in the BSD header files:
//
#define BOOST_NO_CWCHAR
//
// The BSD <ctype.h> has macros only, no functions:
//
#define BOOST_NO_CTYPE_FUNCTIONS
//
// thread API's not auto detected:
//
#define BOOST_HAS_SCHED_YIELD
#define BOOST_HAS_NANOSLEEP
#define BOOST_HAS_GETTIMEOFDAY
#define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE
// boilerplate code:
#define BOOST_HAS_UNISTD_H
#include <boost/config/posix_features.hpp>

View File

@@ -0,0 +1,37 @@
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
// cygwin specific config options:
#define BOOST_PLATFORM "Cygwin"
#define BOOST_NO_CWCTYPE
#define BOOST_NO_CWCHAR
#define BOOST_NO_SWPRINTF
//
// Threading API:
// See if we have POSIX threads, if we do use them, otherwise
// revert to native Win threads.
#define BOOST_HAS_UNISTD_H
#include <unistd.h>
#if defined(_POSIX_THREADS) && (_POSIX_THREADS+0 >= 0) && !defined(BOOST_HAS_WINTHREADS)
# define BOOST_HAS_PTHREADS
# define BOOST_HAS_SCHED_YIELD
# define BOOST_HAS_GETTIMEOFDAY
# define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE
#else
# if !defined(BOOST_HAS_WINTHREADS)
# define BOOST_HAS_WINTHREADS
# endif
# define BOOST_HAS_FTIME
#endif
// boilerplate code:
#include <boost/config/posix_features.hpp>

View File

@@ -0,0 +1,28 @@
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
// hpux specific config options:
#define BOOST_PLATFORM "HP-UX"
// In principle, HP-UX has a nice <stdint.h> under the name <inttypes.h>
// However, it has the following problem:
// Use of UINT32_C(0) results in "0u l" for the preprocessed source
// (verifyable with gcc 2.95.3, assumed for HP aCC)
// #define BOOST_HAS_STDINT_H
#define BOOST_NO_SWPRINTF
#define BOOST_NO_CWCTYPE
// boilerplate code:
#define BOOST_HAS_UNISTD_H
#include <boost/config/posix_features.hpp>
#ifndef BOOST_HAS_GETTIMEOFDAY
// gettimeofday is always available
#define BOOST_HAS_GETTIMEOFDAY
#endif

View File

@@ -0,0 +1,24 @@
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
// SGI Irix specific config options:
#define BOOST_PLATFORM "SGI Irix"
#define BOOST_NO_SWPRINTF
//
// these are not auto detected by POSIX feature tests:
//
#define BOOST_HAS_GETTIMEOFDAY
#define BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE
// boilerplate code:
#define BOOST_HAS_UNISTD_H
#include <boost/config/posix_features.hpp>

View File

@@ -0,0 +1,87 @@
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
// linux specific config options:
#define BOOST_PLATFORM "linux"
// make sure we have __GLIBC_PREREQ if available at all
#include <cstdlib>
//
// <stdint.h> added to glibc 2.1.1
// We can only test for 2.1 though:
//
#if defined(__GLIBC__) && ((__GLIBC__ > 2) || ((__GLIBC__ == 2) && (__GLIBC_MINOR__ >= 1)))
// <stdint.h> defines int64_t unconditionally, but <sys/types.h> defines
// int64_t only if __GNUC__. Thus, assume a fully usable <stdint.h>
// only when using GCC.
# if defined __GNUC__
# define BOOST_HAS_STDINT_H
# endif
#endif
//
// como on linux doesn't have std:: c functions:
//
#ifdef __COMO__
# define BOOST_NO_STDC_NAMESPACE
#endif
//
// If glibc is past version 2 then we definitely have
// gettimeofday, earlier versions may or may not have it:
//
#if defined(__GLIBC__) && (__GLIBC__ >= 2)
# define BOOST_HAS_GETTIMEOFDAY
#endif
#ifdef __USE_POSIX199309
# define BOOST_HAS_NANOSLEEP
#endif
#if defined(__GLIBC__) && defined(__GLIBC_PREREQ)
// __GLIBC_PREREQ is available since 2.1.2
// swprintf is available since glibc 2.2.0
# if !__GLIBC_PREREQ(2,2) || (!defined(__USE_ISOC99) && !defined(__USE_UNIX98))
# define BOOST_NO_SWPRINTF
# endif
#else
# define BOOST_NO_SWPRINTF
#endif
// boilerplate code:
#define BOOST_HAS_UNISTD_H
#include <boost/config/posix_features.hpp>
#ifndef __GNUC__
//
// if the compiler is not gcc we still need to be able to parse
// the GNU system headers, some of which (mainly <stdint.h>)
// use GNU specific extensions:
//
# ifndef __extension__
# define __extension__
# endif
# ifndef __const__
# define __const__ const
# endif
# ifndef __volatile__
# define __volatile__ volatile
# endif
# ifndef __signed__
# define __signed__ signed
# endif
# ifndef __typeof__
# define __typeof__ typeof
# endif
# ifndef __inline__
# define __inline__ inline
# endif
#endif

View File

@@ -0,0 +1,59 @@
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
// Mac OS specific config options:
#define BOOST_PLATFORM "Mac OS"
// If __MACH__, we're using the BSD standard C library, not the MSL:
#if defined(__MACH__)
# define BOOST_NO_CTYPE_FUNCTIONS
# define BOOST_NO_CWCHAR
# ifndef BOOST_HAS_UNISTD_H
# define BOOST_HAS_UNISTD_H
# endif
// boilerplate code:
# include <boost/config/posix_features.hpp>
# ifndef BOOST_HAS_STDINT_H
# define BOOST_HAS_STDINT_H
# endif
//
// BSD runtime has pthreads, sched_yield and gettimeofday,
// of these only pthreads are advertised in <unistd.h>, so set the
// other options explicitly:
//
# define BOOST_HAS_SCHED_YIELD
# define BOOST_HAS_GETTIMEOFDAY
# ifndef __APPLE_CC__
// GCC strange "ignore std" mode works better if you pretend everything
// is in the std namespace, for the most part.
# define BOOST_NO_STDC_NAMESPACE
# endif
#else
// We will eventually support threads in non-Carbon builds, but we do
// not support this yet.
# if TARGET_CARBON
# define BOOST_HAS_MPTASKS
// The MP task implementation of Boost Threads aims to replace MP-unsafe
// parts of the MSL, so we turn on threads unconditionally.
# define BOOST_HAS_THREADS
// The remote call manager depends on this.
# define BOOST_BIND_ENABLE_PASCAL
# endif
#endif

View File

@@ -0,0 +1,19 @@
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
// sun specific config options:
#define BOOST_PLATFORM "sun"
#define BOOST_HAS_GETTIMEOFDAY
// boilerplate code:
#define BOOST_HAS_UNISTD_H
#include <boost/config/posix_features.hpp>

View File

@@ -0,0 +1,39 @@
// (C) Copyright Boost.org 2001. Permission to copy, use, modify, sell and
// distribute this software is granted provided this copyright notice appears
// in all copies. This software is provided "as is" without express or implied
// warranty, and with no claim as to its suitability for any purpose.
// See http://www.boost.org for most recent version.
// Win32 specific config options:
#define BOOST_PLATFORM "Win32"
#if defined BOOST_DECL_EXPORTS
# if defined BOOST_DECL_IMPORTS
# error Not valid to define both BOOST_DECL_EXPORTS and BOOST_DECL_IMPORTS
# endif
# define BOOST_DECL __declspec(dllexport)
#elif defined BOOST_DECL_IMPORTS
# define BOOST_DECL __declspec(dllimport)
#else
# define BOOST_DECL
#endif
#if defined(__GNUC__) && !defined(BOOST_NO_SWPRINTF)
# define BOOST_NO_SWPRINTF
#endif
#ifndef BOOST_DISABLE_WIN32
//
// Win32 will normally be using native Win32 threads,
// but there is a pthread library avaliable as an option:
//
#ifndef BOOST_HAS_PTHREADS
# define BOOST_HAS_WINTHREADS
#endif
// WEK: Added
#define BOOST_HAS_FTIME
#endif

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