The problem here is that we allow programs to do runtime CPU checks. So the minimum set of features required to run a given function might be different from the minimum set of features required to run a program which contains that function.
To make that work, the set of features marked in the module needs to come exclusively from command-line flags, not frontend attributes on a specific function.
Doesn’t that assume that users consistently use target attributes for runtime CPU check guarded functions? I’ve seen a combination of that and building the translation units containing the guarded functions with -mcpu or -march. Of course, in the latter case the object file attributes will end up wrong.
If we want these object file attributes to be more useful, I think a different approach is necessary. For example, the attributes could be derived from the subtarget features of the main function and functions in .init_array, because those functions will be called unconditionally if the binary is run.
But if we want to make the assumption for now that target attributes are used consistently, then I suppose it would be valid to use a module flag to convey the information. The module flag could perhaps just directly contain the information that would go into the object file (e.g. the e_flags bitmask), so there’s less temptation to use it for a different purpose.
In any case, it’s not quite the same thing as the set of target features for sanitizer constructors: some “target features” refer to things that aren’t actually architectural features.
Indeed, I cited a couple of examples in my first message. I think that is a point in favor of only encoding in module flags what will actually get written to the object file.