[cfe-dev] #pragmas in the AST.

Chris Lattner clattner at apple.com
Tue Dec 9 14:38:44 PST 2008


On Dec 9, 2008, at 2:31 PM, Eli Friedman wrote:
> 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.

I completely agree.

> 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.

Sure, that would also be nice.  It would have to be more than just a  
statement, because it can occur at global scope too.  However, all is  
possible if someone cared enough.

> 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.

Actually, I'd prefer to avoid that.  -flimited-precision is really a  
short-term hack due to lack of decent infrastructure.  We're really  
like "limited precision" to be an attribute on a variable/typedef,  
something like:

typedef float __attribute__((limited_precision(12))) float12;

and then have operations tagged with their precision.  This way you  
can have fully precise and imprecise values live and active in the  
same scope.  -flimited-precision happened because noone wanted to hack  
the GCC f.e. to do this, and LLVM IR isn't capable of representing it  
well yet anyway... so a global flag was born! :(

-Chris



More information about the cfe-dev mailing list