[cfe-dev] How to inline a C-function during code generation ?

David Blaikie dblaikie at gmail.com
Tue May 26 13:13:33 PDT 2015


On Tue, May 26, 2015 at 1:12 PM, David Blaikie <dblaikie at gmail.com> wrote:

>
>
> On Tue, May 26, 2015 at 12:56 PM, Nat! <nat at mulle-kybernetik.com> wrote:
>
>>
>> > Am 26.05.2015 um 18:57 schrieb David Blaikie <dblaikie at gmail.com>:
>> >
>> >
>> >
>> > On Mon, May 25, 2015 at 11:05 AM, Nat! <nat at mulle-kybernetik.com>
>> wrote:
>> > Hi
>> >
>> > I started hacking on clang itself and I have some questions, that I
>> couldn't figure out with the help of the source code or the documentation.
>> >
>> > Looking at the IR code generated by -O2 and -O0 it seems, that function
>> inlining is done in clang already. But I haven't figured out, how that is
>> actually done.
>> >
>> > Here's some useful terminology for this discussion:
>> >
>> > IRGen: Clang's generation of LLVM IR from Clang ASTs
>>
>> > CodeGen: LLVM's generation of machine code/assembly from LLVM IR
>> OK, clang unfortunately calls IR generation also code generation, which
>> makes it a bit confusing for the newcomer.
>>
>
> Yep, one day we'll rename it.
>
>
>>
>> > Clang: The Clang frontend, down to the point that it generates and
>> passes LLVM IR to the LLVM libraries.
>> > LLVM: Everything else. (the middle and backend)
>> >
>> > Clang does not do inlining.
>> > LLVM does inlining.
>> > Clang produces code that can be/is encouraged to be/is required to be
>> inlined by LLVM.
>> >
>> > For example, if the user writes source code with the always_inline (or
>> is it "alwaysinline", I forget) attribute, then Clang produces LLVM IR with
>> the matching attribute and LLVM obeys the request (where possibly) and
>> inlines all calls to that function during LLVM's optimization passes.
>>
>> My mental model of what was happening was:
>>
>> <file.c> > cc1 > <file.ir> and then llc < file.ir > file.o
>>
>> and I expected all optimizations to be done after cc1 is complete. This
>> is not the case. The inlining is done in the cc1 stage, during
>> EmitBackendOutput. So that what you would call the "middle" and the code
>> that does the inlining is linked in from the llvm project.
>
>
> That's sometimes called the "middle end" or "target independent
> optimizations" or "IR optimizers/optimizations", etc.
>
>
>> The ir that I got from -cc1 -emit-llvm was therefore not created by
>> "pure" clang as I expected but a mix of clang and llvm.
>>
>
> Right. If you want literally the IR that Clang produced (& was going to
> give to LLVM) you need to pass -mllvm -disable-llvm-optzns. Without that,
> even at -O0, you'll get some LLVM optimizations running, including the
> AlwaysInliner (the version of teh inliner responsible for inlining
> always_inline functions - since that has to be done even at -O0).
>
>
>>
>> I hope I can get substitute my debugging clang by doing cc1 -emit-llvm
>> -O0 and then llc these with optimization on, as it would be a lot easier to
>> debug, why my code does not get inlined.
>>
>
& I'd suggest passing the .ll/.bc back to clang, rather than llc - as llc
and Clang don't necessarily use precisely the same optimization pipeline.


>
>> Thanks for the helpful reply!
>>
>> Ciao
>>    Nat!
>> ------------------------------------------------------
>> Wir haben das Beste gewollt, aber es kam wie immer.
>>                                     - W.Tschernomyrdin
>>
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150526/54995d8c/attachment.html>


More information about the cfe-dev mailing list