- Feb 24, 2005
-
-
Reid Spencer authored
LLVM_CONFIG_PROJECT macro. llvm-svn: 20313
-
Reid Spencer authored
recommended configuration of projects is now much simplified and depends on LLVM file presence rather than local project file presence. llvm-svn: 20312
-
Reid Spencer authored
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
-
Reid Spencer authored
* 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
-
Reid Spencer authored
llvm-svn: 20309
-
Chris Lattner authored
llvm-svn: 20308
-
Reid Spencer authored
* Make aclocal look in LLVM's autoconf/m4 directory for macros * Don't force generation of missing files llvm-svn: 20307
-
Andrew Lenharth authored
llvm-svn: 20306
-
Reid Spencer authored
in the config.status script. This allows the AC_CONFIG_MAKEFILE macro to work properly after it was changed to support sub-projects. llvm-svn: 20305
-
Reid Spencer authored
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
-
Reid Spencer authored
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
-
Chris Lattner authored
reporting the problem and exiting. llvm-svn: 20302
-
Reid Spencer authored
llvm-svn: 20301
-
Chris Lattner authored
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
-
Chris Lattner authored
All CFG edges to DEAD should be eliminated. llvm-svn: 20299
-
Chris Lattner authored
llvm-svn: 20298
-
Chris Lattner authored
llvm-svn: 20297
-
Chris Lattner authored
llvm-svn: 20296
-
Chris Lattner authored
llvm-svn: 20295
-
Reid Spencer authored
* 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
-
Chris Lattner authored
llvm-svn: 20293
-
Tanya Lattner authored
Only print out machine instructions before modulo scheduling if we are actually doing modulo scheduling! :) llvm-svn: 20292
-
Chris Lattner authored
llvm-svn: 20291
-
- Feb 23, 2005
-
-
Andrew Lenharth authored
llvm-svn: 20290
-
Chris Lattner authored
llvm-svn: 20289
-
Chris Lattner authored
llvm-svn: 20288
-
Chris Lattner authored
llvm-svn: 20287
-
Chris Lattner authored
this reduces the time for -simplifycfg in a debug build from 106s to 14.82s llvm-svn: 20286
-
Chris Lattner authored
*** 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
-
Chris Lattner authored
llvm-svn: 20284
-
Tanya Lattner authored
llvm-svn: 20280
-
Chris Lattner authored
llvm-svn: 20279
-
Andrew Lenharth authored
llvm-svn: 20278
-
Chris Lattner authored
llvm-svn: 20277
-
Chris Lattner authored
llvm-svn: 20276
-
Chris Lattner authored
llvm-svn: 20275
-
Chris Lattner authored
llvm-svn: 20274
-
- Feb 22, 2005
-
-
Andrew Lenharth authored
llvm-svn: 20273
-
Chris Lattner authored
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
-
Andrew Lenharth authored
llvm-svn: 20264
-