Actually teach dsa about select instructions. This doesn't affect the
graph in any way other than not setting a spurious U marker on pointer
nodes that are selected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@20324 91177308-0d34-0410-b5e6-96231b3b80d8
X = gep null, ...
Used to not create a scalar map entry for X, which caused clients to barf.
This is bad.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@20316 91177308-0d34-0410-b5e6-96231b3b80d8
recommended configuration of projects is now much simplified and depends
on LLVM file presence rather than local project file presence.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@20312 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@20311 91177308-0d34-0410-b5e6-96231b3b80d8
* 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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@20310 91177308-0d34-0410-b5e6-96231b3b80d8
* Make aclocal look in LLVM's autoconf/m4 directory for macros
* Don't force generation of missing files
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@20307 91177308-0d34-0410-b5e6-96231b3b80d8
in the config.status script. This allows the AC_CONFIG_MAKEFILE macro to
work properly after it was changed to support sub-projects.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@20305 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@20304 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@20303 91177308-0d34-0410-b5e6-96231b3b80d8
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! :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@20300 91177308-0d34-0410-b5e6-96231b3b80d8
* 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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@20294 91177308-0d34-0410-b5e6-96231b3b80d8
*** 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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@20285 91177308-0d34-0410-b5e6-96231b3b80d8
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 :-/
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@20265 91177308-0d34-0410-b5e6-96231b3b80d8
