<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 1, 2009, at 8:55 AM, Daniel Dunbar wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Tue, Sep 1, 2009 at 8:36 AM, Douglas Gregor<<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>> wrote:<br><blockquote type="cite">On Aug 31, 2009, at 10:51 PM, Daniel Dunbar wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">Eventually we will probably also want a feature '-write-ast' (or so)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">which will output an AST while doing other things (like compiling),<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">but that is not part of this proposal.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">One salient design point is that the default suffix for AST files is<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">'.ast', which does not indicate the source language. This means the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">driver won't be able to make decisions about things like code<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">generator options based on its language.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">If nothing else, we need to know when the AST file is a C++ file, so that we<br></blockquote><blockquote type="cite">can link in the C++ standard library.<br></blockquote><br>Actually, thats just based on the driver entry point (clang vs<br>clang++), not the language! Although one could argue that should<br>change...<br></div></blockquote><div><br></div>Oh, right! So... what kinds of decisions does the driver actually have to make that affect options to the code generator?</div><div><br></div><div><blockquote type="cite"><div><blockquote type="cite"><blockquote type="cite">I'm not sure yet if this<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">matters. If it did we would either (a) have to poke the .ast to figure<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">out its language, or (b) use -x with new options like c++-ast etc<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">(like for preprocessed inputs) and optionally use suffixes like<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">'.c-ast', '.cpp-ast', etc.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">We should poke the AST file for this information.<br></blockquote><br>I agree, but its worth noting the downside of this is that the driver<br>would have to link in substantially more code (or use a custom method<br>to get the language, for example we could arrange the language to be<br>part of the file header).<br></div></blockquote><div><br></div><div>It's just the bitstream reader; we can factor out code that identifies a PCH file and decodes LangOptions without dragging in the rest of the PCH reader.</div><br><blockquote type="cite"><div><blockquote type="cite"><blockquote type="cite">A patch following this design is attached. The compile-ast option is<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">not implemented in clang, and I don't know exactly what model we want<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">for compile options passed to an ast -> .s compile step (most of them<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">are backed in the .ast, but not all of them).<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">If we do nothing, we'll end up checking the AST-backed options (complaining<br></blockquote><blockquote type="cite">when there are differences) and just passing the other compilation options<br></blockquote><blockquote type="cite">through to CodeGen for generation of the .s file. That seems fine to me.<br></blockquote><br>It's "fine", but its not ultimately what we want, I think. Consider<br>trying to build a Makefile system which would cache AST files, for<br>example. Or a 'ccache' mode which caches .ast files. It's much more<br>likely to want to pass 0 options to the compile-ast step, than have to<br>duplicate the options. That would require us to tuck some extra things<br>in the PCH.<br><br>Similarly, having the driver figure out just which options it should<br>pass for a compile-ast step and which have been subsumed is ugly and<br>error prone. My inclination is that we should just suck all the<br>options into the PCH, so that the driver can pass no options to a<br>compile-ast step. Then if there is a user request for some particular<br>option to be overrideable at the compile-ast stage, we can add that as<br>needed.<br></div></blockquote></div><br><div>Sure, it's easy to suck more options into the AST. At present, we take care of everything in LangOptions, classifying each option as "important" (the same setting as the AST file must be used) or "benign" (the option can be overridden). That includes some code-generation-related flags (Optimize, OptimizeSize, PICLevel<span class="Apple-style-span" style="color: rgb(62, 131, 136); font-family: Menlo; font-size: 11px; "><span class="Apple-style-span" style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; ">) that have an impact on predefined macros, but target-specific flags aren't stored anywhere.</span></span></div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div></body></html>