mjacob added a comment. In http://reviews.llvm.org/D15998#324354, @reames wrote:
> Also, before this gets exposed through Clang, we really should > formalize/document the attribute. In practice, it implies the lack of a > safepoint poll site inside the called function. Annoyingly, it's not an > inferable property since we don't represent the possible insertion of a poll > in the IR. That wouldn't work for my language since it doesn't use polls at all. Instead, a practical definition would be: "a statepoint will not be inserted if the call site or callee has this attribute". My language backend currently relies on this, e.g. if calling printf (currently statepoints don't support vararg callees). > Hm. This makes me wonder... We've moved to a model of inserting safepoints > (specifically for deopt info) early, and then rewriting late in our tree. > We're not even using the PlaceSafepoints pass any more. It's been left > mostly for other users. Would it maybe make sense to fully retire > PlaceSafepoints and migrate over to a scheme where safepoints sites are > explicit from the beginning? This would allow us to infer "gc-leaf" from > FunctionAttrs... With explicit safepoints and the above-mentioned definition the gc-leaf-funtion attribute wouldn't be necessary at all, because then a function is a GC leaf if and only if no safepoint should be inserted when calling this function. > (This high level discussion should probably move to llvm-dev. I can start it > if you'd like, otherwise post something and I'll reply.) I think it makes more sense if you start the discussion because I'm not familiar with your use cases (I only use a subset of safepoint functionality, e.g. no safepoint polls). http://reviews.llvm.org/D15998 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
