Similar to X86, it should be safe to inline callees if their
target-features are a subset of the caller. As some subtarget features
provide different instructions depending on whether they are set or
unset (e.g. ThumbMode and ModeSoftFloat), we use a whitelist of
target-features describing hardware capabilities only.
Details
Diff Detail
Event Timeline
Ping, any thoughts on this? I committed a similar patch for AArch64 recently (D34698).
This looks like a straight forward and sensible implementation of a target hook to me. But before committing, perhaps someone with more inlining experience than me can have a quick look as well.
Thanks Sjoerd! I'll hold of committing this until tomorrow so people in other timezones can voice concerns.
lib/Target/ARM/ARMTargetTransformInfo.cpp | ||
---|---|---|
31 | Are you sure ModeThumb is the only feature we need to check for? ModeSoftFloat in particular seems suspicious: VFP intrinsics in the callee could fail to compile. (I'd be much happier if we were whitelisting features; I'm afraid of missing something.) |
lib/Target/ARM/ARMTargetTransformInfo.cpp | ||
---|---|---|
31 | Thanks for pointing out ModeSoftFloat, which behaves similar to ModeThumb. They both force different modes, with different instructions available, depending whether they are set or unset. I think ideally they shouldn't be subtarget features, as my understanding was that subtarget features should only provide additional capabilities/instructions when they are enabled. But I guess that would a far bigger change and a whitelist should be fine for now. |
lib/Target/ARM/ARMTargetTransformInfo.cpp | ||
---|---|---|
34 | ARM::FeatureD16 and FeatureVFPOnlySP are also suspicious... not because they're different modes, but because having the feature enabled does the opposite of what you would expect. |
Removed FeatureD16 and FeatureVFPOnlySP from the whitelist, thanks again @efriedma . I've also moved the whitelist to ARMTargetTransformInfo::InlineFeatureWhitelist so it does only get instantiated once.
I'll hold off committing this until tomorrow, to give people a chance to raise concerns with moving the whitelist to a member variable in ARMTargetTransformInfo.
Are you sure ModeThumb is the only feature we need to check for? ModeSoftFloat in particular seems suspicious: VFP intrinsics in the callee could fail to compile. (I'd be much happier if we were whitelisting features; I'm afraid of missing something.)