Provide post-link-optimization in llvmc and gccld

[llvmbot]

Bugzilla Link	512
Resolution	FIXED
Resolved on	Feb 22, 2010 12:54
Version	trunk
OS	All
Reporter	LLVM Bugzilla Contributor

Extended Description

This enhancement requests that the llvmc and gccld tools support a
-post-link-opt= option that allows the user to specify a "pass" to be run on the
linked bytecode before code generation occurs. For example, we want to be able
to say:

llvmc x.bc y.bc -o a.out -post-link-opt=FOO

which means that the following steps would occur:

1. x.bc and y.bc are linked together to produce llvm.bc
2. The "FOO" program is invoked to process llvm.bc and return a new bytecode
   file. FOO is passed the full path to llvm.bc in the first argument and the
   name of a temporary file it should create as the second argument.
3. If FOO returns a non-zero result code, processing stops.
4. If FOO returns a zero result code, the temporary file is read in and
   validated.
5. If the file validates correctly, it is used for code generation resulting in
   the creation of the a.out file.

The idea is to allow separate programs to post-process a linked program. For
example, the pool allocator could be just a program that gets downloaded and
used like:

llvmc x.c y.c -postlinkopt=poolalloc -o xy.out

[llvmbot]

I think the postlink opt should be a list of passes possibly found in a
loadable library specifed by -load instead of another executable. This will be
faster too (no extra I/O for reading/writing bytecode).

[llvmbot]

llvm-ld already has a -load option that specifies a module with well-defined
interfaces for running additional arbitrary passes. This enhancement is in
addition to the -load option. If I recall correctly, its something that Chris
and I determined would be useful as a more generic (not LLVM version sensitive)
way to do optimization, albeit (as you mentioned) a little slower.

[llvmbot]

Feature Implemented.

This patch adds a -post-link-opts option to llvm-ld which allows an arbitrary
program to optimize bytecode after linking. The program is passed two file
names. The first is the input (linked bytecode) the second is where it must
place its output (presumably after optimizing). If the output file is bytecode
(after the program is run), it is used as a substitute for the input for further
linking steps. This will allow things like poolalloc to be written as a
separate program instead of a loadable module or built into LLVM.

Patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20051219/030262.html

[llvmbot]

Note:

Changes were not necessary to llvmc because the -Tlnk option already provides
the passthrough ability. So, to tell llvmc to use the -post-link-opts option, use:

-Tlnk=-post-link-opt=/opt_program

where /opt_program is the path to the post-link optimization program.