[PATCH] New external2availableexternally pass

When we have a runtime library, it's useful to expose that library to the optimizers, but it's bad to ask LLVM to actually codegen the library's code a second time.

This pass name is uncomfortably long. I'd be happy to accept any suggestions for the name.

[Jeffrey Yasskin, 2009-12-05 22:57:23]

Please take a look: http://codereview.appspot.com/download/issue166075_1.diff

[baldrick_free.fr, 2009-12-06 08:35:56]

Hi,

> When we have a runtime library, it's useful to expose that library to
> the optimizers, but it's bad to ask LLVM to actually codegen the
> library's code a second time.

I didn't look at the code, but it sounds like it gives functions
available_externally linkage.  Why not have the front-end output
the functions with available_externally linkage in the first place?

Ciao,

Duncan.

[Jeffrey Yasskin, 2009-12-06 10:32:07]

On Sun, Dec 6, 2009 at 12:35 AM, Duncan Sands <baldrick@free.fr> wrote:
> Hi,
>
>> When we have a runtime library, it's useful to expose that library to
>> the optimizers, but it's bad to ask LLVM to actually codegen the
>> library's code a second time.
>
> I didn't look at the code, but it sounds like it gives functions
> available_externally linkage.

Yes.

> Why not have the front-end output
> the functions with available_externally linkage in the first place?

1. I knew how to write this pass; modifying clang would have required
learning more.
2. It seems useful to be able to compile the runtime library to .bc
with external functions, codegen the .o from that for the real runtime
library, and then convert it to the available_externally form for use
by application optimizers and JITs. A front-end flag would require
compiling from C twice.
3. dgregor endorsed the idea of this patch, although I didn't mention
the possibility of a clang flag.

But let me know if an extra clang flag would be preferable. I'll
probably wind up writing a standalone tool for Unladen instead of
shaving that yak, but I wouldn't object strongly to dropping this
patch.

[Jeffrey Yasskin (google), 2009-12-07 19:52:18]

Anyone have comments?

On Sun, Dec 6, 2009 at 2:32 AM, Jeffrey Yasskin <jyasskin@gmail.com> wrote:
> On Sun, Dec 6, 2009 at 12:35 AM, Duncan Sands <baldrick@free.fr> wrote:
>> Hi,
>>
>>> When we have a runtime library, it's useful to expose that library to
>>> the optimizers, but it's bad to ask LLVM to actually codegen the
>>> library's code a second time.
>>
>> I didn't look at the code, but it sounds like it gives functions
>> available_externally linkage.
>
> Yes.
>
>> Why not have the front-end output
>> the functions with available_externally linkage in the first place?
>
> 1. I knew how to write this pass; modifying clang would have required
> learning more.
> 2. It seems useful to be able to compile the runtime library to .bc
> with external functions, codegen the .o from that for the real runtime
> library, and then convert it to the available_externally form for use
> by application optimizers and JITs. A front-end flag would require
> compiling from C twice.
> 3. dgregor endorsed the idea of this patch, although I didn't mention
> the possibility of a clang flag.
>
> But let me know if an extra clang flag would be preferable. I'll
> probably wind up writing a standalone tool for Unladen instead of
> shaving that yak, but I wouldn't object strongly to dropping this
> patch.
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>

[eli.friedman_gmail.com, 2009-12-07 20:15:36]

On Mon, Dec 7, 2009 at 11:52 AM, Jeffrey Yasskin <jyasskin@google.com> wrote:
> Anyone have comments?

I don't see any issues with the code.

-Eli

[clattner_apple.com, 2009-12-07 20:59:08]

On Dec 7, 2009, at 11:52 AM, Jeffrey Yasskin wrote:

> Anyone have comments?

Who are the expected clients of this?  It seems pretty special purpose to go
into mainline.

-Chris

> On Sun, Dec 6, 2009 at 2:32 AM, Jeffrey Yasskin <jyasskin@gmail.com> wrote:
>> On Sun, Dec 6, 2009 at 12:35 AM, Duncan Sands <baldrick@free.fr> wrote:
>>> Hi,
>>> 
>>>> When we have a runtime library, it's useful to expose that library to
>>>> the optimizers, but it's bad to ask LLVM to actually codegen the
>>>> library's code a second time.
>>> 
>>> I didn't look at the code, but it sounds like it gives functions
>>> available_externally linkage.
>> 
>> Yes.
>> 
>>>  Why not have the front-end output
>>> the functions with available_externally linkage in the first place?
>> 
>> 1. I knew how to write this pass; modifying clang would have required
>> learning more.
>> 2. It seems useful to be able to compile the runtime library to .bc
>> with external functions, codegen the .o from that for the real runtime
>> library, and then convert it to the available_externally form for use
>> by application optimizers and JITs. A front-end flag would require
>> compiling from C twice.
>> 3. dgregor endorsed the idea of this patch, although I didn't mention
>> the possibility of a clang flag.
>> 
>> But let me know if an extra clang flag would be preferable. I'll
>> probably wind up writing a standalone tool for Unladen instead of
>> shaving that yak, but I wouldn't object strongly to dropping this
>> patch.
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

[Jeffrey Yasskin (google), 2009-12-07 21:06:19]

On Mon, Dec 7, 2009 at 12:59 PM, Chris Lattner <clattner@apple.com> wrote:
>
> On Dec 7, 2009, at 11:52 AM, Jeffrey Yasskin wrote:
>
>> Anyone have comments?
>
> Who are the expected clients of this?  It seems pretty special purpose to go
into mainline.

People writing JITs are likely to use it to provide definitions of
their runtime library functions. Static compilers could use it too if
they ship with a compiled runtime but also want to be able to inline
bits of the runtime into their output, without making those bits
builtins.

[Jeffrey Yasskin (google), 2009-12-08 00:14:54]

On Mon, Dec 7, 2009 at 1:06 PM, Jeffrey Yasskin <jyasskin@google.com> wrote:
> On Mon, Dec 7, 2009 at 12:59 PM, Chris Lattner <clattner@apple.com> wrote:
>>
>> On Dec 7, 2009, at 11:52 AM, Jeffrey Yasskin wrote:
>>
>>> Anyone have comments?
>>
>> Who are the expected clients of this?  It seems pretty special purpose to go
into mainline.
>
> People writing JITs are likely to use it to provide definitions of
> their runtime library functions. Static compilers could use it too if
> they ship with a compiled runtime but also want to be able to inline
> bits of the runtime into their output, without making those bits
> builtins.

That is, take the author of a new language.
1. They write a compiler, taking their language to IR.
2. They write a standard library, which they'll ship with their
compiler. To make compilation fast, they generate native code from the
library and install it with their compiler.
3. They notice that calls into their standard library could benefit
from inlining. There are two things they could do here:
  a. Don't install native code; instead install .bc files. Load those
into the module of each translation unit. This means that for stdlib
calls that aren't inlined, every compilation needs to generate code.
That's especially problematic for a JIT, but also wastes time for a
static compiler.
  b. Generate a .bc file with the library functions defined, but
marked available_externally. This lets the optimizers inline the
definitions, but non-inlined definitions just call out to the
pre-compiled native code.

3b is the tactic this pass is designed for. The language author uses it like:
1. Write the compiler.
2. Write the standard library.
3. Compile it to bitcode.
4. Generate a .o or .so from the bitcode, and install that with the
compiler. This gets linked with every output binary.
5. Run external2availableexternally over the bitcode file, to produce
a stdlib.bc. This gets loaded into the Module of every translation
unit to facilitate inlining.

Jeffrey