[cfe-dev] #pragmas in the AST.

Eli Friedman eli.friedman at gmail.com
Tue Dec 9 14:31:37 PST 2008


On Tue, Dec 9, 2008 at 10:44 AM, Chris Lattner <clattner at apple.com> wrote:
> Yep, Steve's right.  When we eventually support FENV_ACCESS (for
> example) there are two reasonable ways to implement it:
>
> 1) make it synthesize a 'FENV_ACCESS statement' of some sort when in
> function scope.  I don't really like this, but it is possible.
> 2) make it set the current mode in Sema, have the scope mechanism
> maintain the mode as part of the scope stack.  When any fp operation
> is seen, the AST node for that fp operation would be tagged with the
> mode it is in.

We definitely want the operations to be tagged somehow so that the
expression can be evaluated without context by code like
Expr::Evaluate, we can implement a command-line option without the
code using the AST being aware of it, etc.  Doing otherwise would be a
serious pain to the point where I can't imagine an implementation that
worked in that way without heavy modifications to the codebase.  And
noting the pragma in the scope stack seems like the obvious way to do
this.

On the other hand, I think we also want to be represent FP-related
pragmas in the AST; it should be relatively easy (just a matter of
stuffing in an extra statement when we see one), and I can definitely
imagine use-cases.  One possible use: one could write a rewriter
depending on a special FP library to rewrite out FENV_ACCESS for
compilers which don't support it (it would suck for performance, but
it seems like it would be feasible).  Without an AST node, there's no
easy way to figure out the location of the pragma, which the rewriter
would want to remove.  Another use, with a similar idea: suppose clang
implements a pragma-based version of llvm-gcc's -flimited-precision
("#pragma CLANG_FP limited_precision(12)" or something like that).
Someone then might want to be able to use the rewriter to rewrite the
code (possibly in a platform-specific way), and then remove the
pragma.

-Eli



More information about the cfe-dev mailing list