llvm dev - Jul 2010 - [LLVMdev] inline callsites whose function definitions are in different file?

On 7/27/2010 12:40 PM, Devang Patel wrote:
> On Tue, Jul 27, 2010 at 7:46 AM, Chuck Zhao<czhao at
eecg.toronto.edu>  wrote:
>>   LLVM (2.7 release version) provides 2 implementations for inlining
>> function callsites:
>>
>> - InlineSimple.cpp (-inline):               inline simple callsites
>> according to its cost analysis
>> - InlineAlways.cpp (-always-inline):  inline all callsites that are
>> marked with "always_inline" attribute.
>>
>> They are both subclasses of Inline.cpp that assumes the function's
>> definition (body) is in the same Module (file) as its callsites (that
>> will be inlined).
>>
>>
>> I am now having a situation that the functions are defined in file1.c
>> (Module1) but all callsites are spread in file2, file3, ...fileN. Would
>> LLVM be able to inline such callsites at compile time?
>>
>> I think the right approach is to conduct inlining at link time (via the
>> LTO), but still wonder if it is possible to do it at compile time
>> without heavy hacking.
> At compiler time while compiling file2.c, how would compile know about
> function definition in file1.c  ?
> -
> Devang
I don't, and the compiler doesn't neither, that is the problem, unless I
do hacking at compile time.
E.g.:
- put all such function's definitions into file1.c
- force to compile file1.c 1st.
- when compiling file2.c:
   . read file1.bc
   . attach to file2's module
   - do inline analysis + inlining
   - detach the attached file1.bc functions
- repeat for other files.
...

But I don't think this is a good/elegant approach, thus asking the 
LLVM-Dev group.


Thank you

Chuck

On Tue, Jul 27, 2010 at 9:46 AM, Chuck Zhao <czhao at eecg.toronto.edu>
wrote:
> I don't, and the compiler doesn't neither, that is the problem,
unless I do
> hacking at compile time.
> E.g.:
> - put all such function's definitions into file1.c
> - force to compile file1.c 1st.
> - when compiling file2.c:
>  . read file1.bc
>  . attach to file2's module
>  - do inline analysis + inlining
>  - detach the attached file1.bc functions
> - repeat for other files.
> ...
This is what LTO does.

One difference is, usually LTO stitches all modules together before
inlining instead of individually attaching/detaching .bc files. This
is because what if file2.c uses a function from file9.c ?

-
Devang

On 7/27/2010 12:53 PM, Devang Patel wrote:
> On Tue, Jul 27, 2010 at 9:46 AM, Chuck Zhao<czhao at
eecg.toronto.edu>  wrote:
>
>> I don't, and the compiler doesn't neither, that is the problem,
unless I do
>> hacking at compile time.
>> E.g.:
>> - put all such function's definitions into file1.c
>> - force to compile file1.c 1st.
>> - when compiling file2.c:
>>   . read file1.bc
>>   . attach to file2's module
>>   - do inline analysis + inlining
>>   - detach the attached file1.bc functions
>> - repeat for other files.
>> ...
> This is what LTO does.
>
> One difference is, usually LTO stitches all modules together before
> inlining instead of individually attaching/detaching .bc files. This
> is because what if file2.c uses a function from file9.c ?
>
> -
> Devang
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Ya, I agree with you. The answer is, do such types of inlining at link time.

Thanks Devang

Chuck