george.burgess.iv added a comment.
> neonfp isn't passed as a feature in the first place; there's a separate API
> setFPMath which is used for that. We translate it into a target feature for
> the sake of the backend. So I'm not sure what you're proposing.
The idea would be for `initFeatureMap` to handle adding `neonfp` instead, so we
can make the `vector&` we're passing into `handleTargetFeatures` a `const
vector&`. An old comment claims that this would be desirable from a refactoring
standpoint
> What happens if someone specifies attribute((target("soft-float-abi"))) or
> something like that? (There's an API isValidFeatureName to validate feature
> names, but we currently don't implement it.)
Good catch. It doesn't appear that that works on its own for the `target`
attribute, since we only filter user attrs, but it's probably something that's
good to diagnose.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D61750/new/
https://reviews.llvm.org/D61750
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
