efriedma-quic wrote: Sorry, I meant to get back to this sooner.
I'm not sure it makes sense to distinguish between "compile-time" and "link-time" in the sense this patch is doing: whether an instrumentation pass runs at compile-time or link-time is more a matter of what's convenient for a given compilation pipeline, not a fundamental semantic difference. The fundamental difference is whether we know the caller: if we know the caller, we can just take the flags from the caller. If we don't, we have to pick some "generic" flags that work for any possible caller. If this means frontends have to do something more complicated to compute the right set of features, or we need to add new flags to clang, I think that's just the cost of doing things correctly. Along those lines, I think we need some sort of merge rule. Some attributes can be merged: for example, whether the target has an atomic add instruction, as opposed to generic ll/sc atomics. Some attributes can't be merged, like whether a register is reserved: there can only be one correct answer. Maybe the answer is just that we don't want a generic "target-features" list at all; we should just have individual module flags for each feature. That way each attribute can specify its own merge rule. We've already effectively started to do this with #83153: we have a bunch of attributes derived from module flags. https://github.com/llvm/llvm-project/pull/98673 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
