[llvm-commits] [PATCH] New external2availableexternally pass (issue166075)

[Chris Lattner]

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 at gmail.com> wrote:
>> On Sun, Dec 6, 2009 at 12:35 AM, Duncan Sands <baldrick at 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 at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits