I'm not convinced this is an excellent approach, in part because I'm unclear on where all we expect to funnel the results of TargetInfo::initFeatureMap. Thought I'd throw it out for review anyway, and see what people with actual context think. :)
The underlying problem I'm trying to solve is that, given the following code with a suitable ARM target,
___attribute__((target("crc"))) void foo() {}
clang ends up codegening a function with the '+soft-float-abi' target feature, which we go out of our way to remove in the frontend for the default target features, since the backend apparently tries to figure out whether the soft float ABI should be used on its own. This is more or less harmless on its own, but it causes the backend to emit a diagnostic directly to errs(). Rather than try to find a way to silence that diag, it seems better to not have to emit it in the first place.
An alternate fix would be to somehow try to filter this in cfe/lib/CodeGen, but there appear to be many callers of initFeatureMap; I get the vague feeling that we shouldn't be letting +soft-float-abi slip through any of them. Again, could be wrong about that due to my lack of familiarity with initFeatureMap's uses.
If we agree that this is a good way forward, there also appears to be +neonfp/-neonfp additions happening in handleTargetFeatures that should prooooobably be happening in initFeatureMap instead? If that's the case, I'm happy to do that as a follow-up, and make it so that handleTargetFeatures no longer mutates its input (which comments indicate would be desirable, along with a more general move of all of this initialization stuff to the construction of our various TargetInfo subclasses).