[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