[cfe-dev] Driver support for AST features (UI Proposal)

[Douglas Gregor]

On Sep 1, 2009, at 8:55 AM, Daniel Dunbar wrote:

> On Tue, Sep 1, 2009 at 8:36 AM, Douglas Gregor<dgregor at apple.com>  
> wrote:
>> On Aug 31, 2009, at 10:51 PM, Daniel Dunbar wrote:
>>> Eventually we will probably also want a feature '-write-ast' (or so)
>>> which will output an AST while doing other things (like compiling),
>>> but that is not part of this proposal.
>>>
>>> One salient design point is that the default suffix for AST files is
>>> '.ast', which does not indicate the source language. This means the
>>> driver won't be able to make decisions about things like code
>>> generator options based on its language.
>>
>> If nothing else, we need to know when the AST file is a C++ file,  
>> so that we
>> can link in the C++ standard library.
>
> Actually, thats just based on the driver entry point (clang vs
> clang++), not the language! Although one could argue that should
> change...

Oh, right! So... what kinds of decisions does the driver actually have  
to make that affect options to the code generator?

>>> I'm not sure yet if this
>>> matters. If it did we would either (a) have to poke the .ast to  
>>> figure
>>> out its language, or (b) use -x with new options like c++-ast etc
>>> (like for preprocessed inputs) and optionally use suffixes like
>>> '.c-ast', '.cpp-ast', etc.
>>
>> We should poke the AST file for this information.
>
> I agree, but its worth noting the downside of this is that the driver
> would have to link in substantially more code (or use a custom method
> to get the language, for example we could arrange the language to be
> part of the file header).

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.

>>> A patch following this design is attached. The compile-ast option is
>>> not implemented in clang, and I don't know exactly what model we  
>>> want
>>> for compile options passed to an ast -> .s compile step (most of  
>>> them
>>> are backed in the .ast, but not all of them).
>>
>> If we do nothing, we'll end up checking the AST-backed options  
>> (complaining
>> when there are differences) and just passing the other compilation  
>> options
>> through to CodeGen for generation of the .s file. That seems fine  
>> to me.
>
> It's "fine", but its not ultimately what we want, I think. Consider
> trying to build a Makefile system which would cache AST files, for
> example. Or a 'ccache' mode which caches .ast files. It's much more
> likely to want to pass 0 options to the compile-ast step, than have to
> duplicate the options. That would require us to tuck some extra things
> in the PCH.
>
> Similarly, having the driver figure out just which options it should
> pass for a compile-ast step and which have been subsumed is ugly and
> error prone. My inclination is that we should just suck all the
> options into the PCH, so that the driver can pass no options to a
> compile-ast step. Then if there is a user request for some particular
> option to be overrideable at the compile-ast stage, we can add that as
> needed.

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) that have  
an impact on predefined macros, but target-specific flags aren't  
stored anywhere.

	- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20090901/3bf37e8d/attachment.html>