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

[Douglas Gregor]

On Sep 1, 2009, at 9:09 AM, Ted Kremenek wrote:

> On Sep 1, 2009, at 8:55 AM, Daniel Dunbar wrote:
>
>>> 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.
>
> Hi Daniel,
>
> I've read what you and others said, and I think this is a great  
> proposal.  Just to be clear, because of the nature of how -O1 and - 
> O2 can produce different ASTs (due to predefines), should I conclude  
> that we would not (in general) be able to share AST files between  
> different compilation modes (e.g., debug build versus optimized  
> build)?

Yes, that is correct. PCH files already have the same limitation, that  
you can't use a debug-built PCH file with an optimized build of a  
translation unit. For -O1/-O2/-Os, we actually have LangOptions bits  
that are encoded in the PCH (and checked at PCH load time).

	- Doug