aaron.ballman added a comment.
In D59467#1439585 <https://reviews.llvm.org/D59467#1439585>, @Tyker wrote:
> about the semantic issue.
> with the standard's latitude on where we can put the attribute, the
> attribute can appear any where on the path of execution and must be matched
> with the condition it corresponds to. we need to do it for diagnostics
> purposes to detect conflicts and repetitions. and we need it again for the
> codegen. but where in the ast can we store this information ?
I feel like this could be tracked in the StmtBits as well as via an attributed
stmt node. We need to be able to handle cases like:
if (foo) [[likely]] {
stmts...
}
if (bar) {
stmts...
[[likely]];
stmts...
}
if (baz)
[[likely]] stmt;
The attributed statement is required because we want ast pretty printing to
also print out the `[[likely]]` attribute usage and AST matchers to
appropriately find the attribute, etc, and we need to know which statement the
attribute was attached to in order to get the positioning correct. However, for
diagnostic purposes, we likely want to know information like "has this path
already been attributed" and that can either be through some extra data on an
AST node, or it could be an Analysis pass like we do for `[[fallthrough]]`
support with a separate pass for CodeGen.
> is adding information to conditional statements Node acceptable ?
You can generally add information to AST nodes, but pay close attention to
things like adding bits to a bit-field that suddenly cause the object size to
increase and see if there are ways to avoid that if possible (and if not, it's
still fine).
It might make sense to work your way backwards from the backend to see what
possible ways we can support this feature. `__builtin_expect` may make sense
for if statements, but for case and default labels in a switch, we may want to
play with the branch weights. For catch handlers, we may need to thread
information through yet another way. Once we know what kinds of paths we can
actually do something interesting with, we may spot a pattern of how to expose
the information through the AST.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D59467/new/
https://reviews.llvm.org/D59467
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
