<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 4 June 2017 at 02:38, Boris Kolpackov <span dir="ltr"><<a href="mailto:boris@codesynthesis.com" target="_blank">boris@codesynthesis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> writes:<br>
<br>
> I think you misunderstood my question. What difference do you expect the -x<br>
> c++-cpp-output / -x c++-module-cpp-output flag to make, compared to passing<br>
> -x c++ / -x c++-module for the same input file? What do you think that flag<br>
> does?<br>
<br>
</span>I believe that -x *cpp-output tells the compiler that what's being<br>
compiled has previously gone through -E. At least that's the GCC's<br>
semantics.<br>
<br>
It is also now clear that this semantics is pretty useless since it<br>
looses information and that's why we have -frewrite-includes and<br>
-fdirectives-only.<br></blockquote><div><br></div><div>Yes. It's also pretty much pointless since the point of -E is to produce a source file that is still a valid input in the original language.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Now if you ask me what I would like -x *cpp-output to mean, it would<br>
be this: The input can still contain comments and line continuations<br>
but no macro expansions/conditions or #include directives.<br>
<br>
My understanding is that the preprocessor is essentially a tokenizer<br>
for the compiler frontend. So in this model a compiler could<br>
substitute a "full preprocessor" with a simpler and maybe faster<br>
tokenizer.<br></blockquote><div><br></div><div>For us at least, this would add complexity (by adding a "no preprocessing" mode) and likely not actually bring about any performance improvement -- the additional checks for "does this identifier have a defined macro" and "is this a # at the start of a line" are extremely cheap. Plus, as you mentioned above, this actually isn't what you want -- for compilers like Clang (and recent versions of GCC) that take into account the provenance of tokens (via macro expansion etc) when issuing diagnostics, preprocessing prior to compilation proper harms the quality of experience of your users.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For what it's worth, I've implemented such a tokenizer in build2[1]<br>
and it turned out not too hairy. We use[2] it to extract module<br>
information from translation units.<br>
<br>
Its performance is about the same as Clang's full preprocessor (-E)<br>
which I think is not bad considering I haven't done any optimization<br>
work and it uses std::istream to read the data.<br></blockquote><div><br></div><div>That's impressive, considering that we have done a lot of tuning on our preprocessor. Perhaps it's time for us to stare at some profiles again and see where we're wasting time.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[1] <a href="https://git.build2.org/cgit/build2/tree/build2/cc/lexer.hxx" rel="noreferrer" target="_blank">https://git.build2.org/cgit/<wbr>build2/tree/build2/cc/lexer.<wbr>hxx</a><br>
    <a href="https://git.build2.org/cgit/build2/tree/build2/cc/lexer.cxx" rel="noreferrer" target="_blank">https://git.build2.org/cgit/<wbr>build2/tree/build2/cc/lexer.<wbr>cxx</a><br>
<br>
[2] <a href="https://git.build2.org/cgit/build2/tree/build2/cc/parser.hxx" rel="noreferrer" target="_blank">https://git.build2.org/cgit/<wbr>build2/tree/build2/cc/parser.<wbr>hxx</a><br>
    <a href="https://git.build2.org/cgit/build2/tree/build2/cc/parser.cxx" rel="noreferrer" target="_blank">https://git.build2.org/cgit/<wbr>build2/tree/build2/cc/parser.<wbr>cxx</a><br>
<span class="HOEnZb"><font color="#888888"><br>
Boris<br>
</font></span></blockquote></div><br></div></div>