[cfe-dev] [llvm-dev] Clang Preprocessor Speed Up

[Yaron Keren via cfe-dev]

Once measured times for one of the Boost libraries example, preprocessing
(-E) was about 20% of total compilation time. This is not typical in
general but quite common with Boost libraries as 100s-1000s files may be
included with tons of macros and nested macros.



2016-03-25 1:29 GMT+02:00 Андрей Серебро <llvm-dev at lists.llvm.org>:

> Hi Mats,
>
> Thanks for the reply. Yep, you are right, the time should be measured and
> I guess I can imagine the typical workflow
>
>    - implement prototype
>    - take bunch of big real projects
>    - compare preprocessing time for initial and changed clang
>    - make conclusion whether the idea is sane or not
>
> About usage - probably, some IDEs can act better for they need iteratively
> relex source for correct autocomplete.
>
> What I'm also curious about is if somebody already did something on this
> or had thought about it.
> If the idea was already thought (which I guess is rather possible), it's
> interesting, did somebody already prove it's useless?
>
> 25.03.2016, 01:59, "mats petersson" <mats at planetcatfish.com>:
>
> First, surely the right place for this discussion is the cfe-dev mailing
> list?
>
> Second, have you determined that this is a noticeable amount of time when
> compiling? I have no idea - in my Pascal compiler, parsing the code is
> ~0.1%, codegen to IR ~1.9% and LLVM 98%. But I'm sure Clang is more complex
> in many ways, so the proportion is probably a bit different - a measurement
> of the time spent expanding macros would probably help determine if it's
> worth doing or not.
>
> --
> Mats
>
> On 24 March 2016 at 22:17, Andy via llvm-dev <llvm-dev at lists.llvm.org>
> wrote:
>
> Hello, folks!
>
> Currently me with one other guy are trying to play with clang. The
> proposal may seem stupid, excuse me, if it was already discussed, we just
> want to try to implement something useful which seems absent for now.
>
> Ok, the idea. It seems interesting to try to make lexer a little bit more
> efficient in terms of macro expanding by applying partial expansion of
> macros. the idea is that some libraries have rather deeply nested macro
> definitions, and each time lexer sees it in code, it reexpands definition
> fully. This seems to be overkill sometimes, for rather often macros are not
> redefined in code, so expansion can be reused.
>
> Of course, the typical nesting is rather low, but for example
> BOOST_PP_REPEAT can cause such situations.
>
> So, the question is, what do you think about possible utility of such
> research and the reasons for you think so?
>
> <https://www.google.ru/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwii-ZW4oNrLAhWrCXMKHcFpA1wQFggfMAA&url=http%3A%2F%2Fwww.boost.org%2Fdoc%2Flibs%2F1_43_0%2Flibs%2Fpreprocessor%2Fdoc%2Fref%2Frepeat.html&usg=AFQjCNEicOX9h6Dsd1M82MOjMV5148Rtkg&sig2=p0GM1-YQQGGwaDMHbeHuiA&cad=rja>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> --
> Regards,
> Andrei Serebro
> tel. +79111758381
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160325/9b8a6144/attachment.html>