recommended configuration of projects is now much simplified and depends
on LLVM file presence rather than local project file presence.
llvm-svn: 20312
avoids version conflict problems with ltmain.sh (libtool), mkinstalldirs
and install-sh. This prevents projects from becoming stale when the LLVM
build system is upgraded or modified.
llvm-svn: 20311
* Make the auxilliary directory be llvm/autoconf not the project's
* Use the LLVM_CONFIG_PROJECT macro to get the --with-llvm{src,obj} args
llvm-svn: 20310
is in ${srcdir}/autoconf because that is only true if the project is LLVM.
For other projects (e.g. sample), we don't want to have to distribute the
mkinstalldirs or install-sh programs because it opens a window of breakage
for projects. So, this change requires that the llvm_src variable be set
up via another AC_CONFIG_COMMANDS call. For LLVM this is done in the
configure.ac. For projects its done in the LLVM_CONFIG_PROJECT macro.
llvm-svn: 20304
takes care of the --with-llvmsrc and --with-llvmobj options for the project
It was moved here from the project's configure.ac file because there is
some tricky handling of the llvm_src variable to tell the project where the
llvm source tree is (for mkinstalldirs and install-sh commands).
llvm-svn: 20303
This does a simple form of "jump threading", which eliminates CFG edges that
are provably dead. This triggers 90 times in the external tests, and
eliminating CFG edges is always always a good thing! :)
llvm-svn: 20300
* Consolidate all "install" usage to the install program/script found by
autoconf which includes the autoconf/install-sh script if necessary
* Change Makefile.rules to not use the -D flag to install but use the
MKDIR command as necessary.
* Change Makefile.rules to differentiate between installation of executable
files and regular data files to get the permission modes correct.
llvm-svn: 20294
*** Attempting to perform final cleanups: Final cleanups failed. Sorry. :( Ple
ase report a bug!
<llc>llc.exe: bytecode didn't read correctly.
llc.exe: bytecode didn't read correctly.
<crash>
Assertion failed: M && "You can't write a null module!!", file c:\llvm\lib\bytec
ode\writer\writer.cpp, line 1094
The fact that llc bombed (in this case) is ok, but bugpoint shouldn't crash after this.
llvm-svn: 20285
Changing 'op' here caused us to not enter the store into a map, causing
reemission of the code!! In practice, a simple loop like this:
no_exit: ; preds = %no_exit, %entry
%indvar = phi uint [ %indvar.next, %no_exit ], [ 0, %entry ] ; <uint> [#uses=3]
%tmp.4 = getelementptr "complex long double"* %P, uint %indvar, uint 0 ; <double*> [#uses=1]
store double 0.000000e+00, double* %tmp.4
%indvar.next = add uint %indvar, 1 ; <uint> [#uses=2]
%exitcond = seteq uint %indvar.next, %N ; <bool> [#uses=1]
br bool %exitcond, label %return, label %no_exit
was being code gen'd to:
.LBBtest_1: # no_exit
movl %edx, %esi
shll $4, %esi
movl $0, 4(%eax,%esi)
movl $0, (%eax,%esi)
incl %edx
movl $0, (%eax,%esi)
movl $0, 4(%eax,%esi)
cmpl %ecx, %edx
jne .LBBtest_1 # no_exit
Note that we are doing 4 32-bit stores instead of 2. Now we generate:
.LBBtest_1: # no_exit
movl %edx, %esi
incl %esi
shll $4, %edx
movl $0, (%eax,%edx)
movl $0, 4(%eax,%edx)
cmpl %ecx, %esi
movl %esi, %edx
jne .LBBtest_1 # no_exit
This is much happier, though it would be even better if the increment of ESI
was scheduled after the compare :-/
llvm-svn: 20265
Reid Spencer