We currently have multiple ways of invoking optimizations in llvm, via gccas, gccld, and opt. If we moved gccas/gccld functionality into opt we could save some footprint size and a significant amount of link time during builds (gccas and gccld are among the largest tools, on the same scale as opt, lli and llc). To accomplish this we would need to: 1. Add an option such as -std-compile-opts to run the gccas "set" of optimizations. 2. Add an option such as -std-link-opts to run the gccld set of optimizations. 3. Add a -verify-each option to opt to enabled the "verify after each pass" feature of gccas/gccld. 4. Adjust llvm-test to use opt and llvm-link with these new options instead of running gccas and gccld. Anyone see any roadblocks on doing this? Anyone think its not a good idea?
seems fine to me, but please split this into one bug for gccas and one for gccld. gccas is much easier to eliminate, it is basically "llvm-as < %s | opt ... " with some magic to handle - disable-inlining and -disable-opt. Could we install a gccas shell script that does the right thing? Having a "compile time optimizer" unit is a very useful thing. -Chris
Okay, this bug is for gccas which we'll do first. We can probably install a gccas shell script to retain the same functionality. I'll open a new PR for gccld.
> Having a "compile time optimizer" unit is a very useful thing. What do you mean by this? An option that does "compile time optimization" ?
> > Having a "compile time optimizer" unit is a very useful thing. > What do you mean by this? An option that does "compile time optimization" ? I just mean it's very convenient to be able to do: llvm-gcc -emit-llvm -S -o foo.ll x.c "some_option_approximating_gccas" foo.ll -o foo.bc llc foo.bc ... -Chris
> I just mean it's very convenient to be able to do: > llvm-gcc -emit-llvm -S -o foo.ll x.c > "some_option_approximating_gccas" foo.ll -o foo.bc > llc foo.bc ... Now I'm more confused. Are you suggesting adding an option to llvm-gcc for this? Or, was that a typo and you meant: llvm-gcc -emit-llvm -S -o foo.ll x.c opt -some-option-approximating-gccas foo.ll -o foo.bc llc foo.bc ... ?
Should opt read assembly as well? It could sense the file type and DTRT. A few more K of code in opt isn't really going to matter much. Then you'd be able to throw output of llvm-gcc -S -emit-llvm directly at opt.
s/some_option_approximating_gccas/some_script_approximating_gccas > Should opt read assembly as well? No. I don't think there is any point in that, but I wouldn't fight it if you REALLY REALLY wanted it. Note that getting it to work with pipes would be a PITA. -Chris
This will be done in several steps: 1. Add gccas functionality to opt 2. Modify llvm-test to use opt instead of gccas and test it. 3. Let some nightly tests run to validate the use of opt. 4. Convert gccas to a shell script that is created both in the build dir and the install target (with appropriate paths to llvm-as and opt). Reid.
I rearranged things a bit. There's no need to mess with llvm-test if we have a plug-compatible gccas shell script. So, these patches do that: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070129/043741.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070129/043742.html This was tested on a variety of llvm-test test cases and it seems to work just fine.
LLVM's footprint has now shrunk by 35.7MBytes (debug build).
This conversion has been completed.