This is an archive of the discontinued LLVM Phabricator instance.

[AArch64] Move default extensions from clang Driver to TargetParser
ClosedPublic

Authored by dmgreen on Jan 11 2023, 9:35 AM.

Details

Summary

As far as I understand these additions of default extensions would be better added in the TargetParser, not by the driver. This removes the addition of "+i8mm" and "+bf16" features as they are already added in 8.6/9.1 architectures. AEK_MOPS and AEK_HBC have been added to 8.8/9.3 architectures to replace the "+hbc" and "+mops" features.

Diff Detail

Event Timeline

dmgreen created this revision.Jan 11 2023, 9:35 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 11 2023, 9:35 AM
dmgreen requested review of this revision.Jan 11 2023, 9:35 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 11 2023, 9:35 AM
Herald added a subscriber: MaskRay. · View Herald Transcript

There's an in-progress version of this for v8.9a in D141404, @pratlucas can you also update that patch maybe?

LGTM, makes sense to move into TP, D141404 should do the same it it makes sense.

tmatheson accepted this revision.Jan 12 2023, 6:34 AM
This revision is now accepted and ready to land.Jan 12 2023, 6:34 AM

It makes sense to move this to the TargetParser and the code looks much better indeed. My only concern is that this changes the driver's behaviour in regards to which target feature flags are passed from clang to the backend.

It looks like the implied features are included in the backend calls for the -mcpu options and, as far as I can tell, those are correctly captured from the TargetParser info. Should we do the same for -march values? Or should we rely strictly in the backend expansion?

It makes sense to move this to the TargetParser and the code looks much better indeed. My only concern is that this changes the driver's behaviour in regards to which target feature flags are passed from clang to the backend.

It looks like the implied features are included in the backend calls for the -mcpu options and, as far as I can tell, those are correctly captured from the TargetParser info. Should we do the same for -march values? Or should we rely strictly in the backend expansion?

Hello. Are you looking at a compiler after D141411 went in? I believe after that it should work as you mention. Let me know if it doesn't or you see any problems.

Also I believe that because in the backend HasV8_8aOps includes FeatureMOPS, the feature would already be enabled in codegen (so long as there isn't -target-feature -mops to disable it). Same for other features that become mandatory like dotprod, bf16 and i8mm. We would like them to be "known" by clang too though, so that it can get things like preprocessor defs and especially target("..") attributes correct.

Sorry, I just noticed my previous comment wasn't clear on what I meant by passing on the target features.
The features are indeed included as part of the IR attributes since D141411, but they are no longer included as -target-feature arguments in calls to cc1 by the clang driver. This is not the case when using -mcpu, for example.
I agree the end result will be the same assuming the information is consistent between the TargetParser and the backend's subtarget features, but I think it would be good to define the what's the clang driver's expected behaviour to avoid any inconsistencies in the future.

Sorry, I just noticed my previous comment wasn't clear on what I meant by passing on the target features.
The features are indeed included as part of the IR attributes since D141411, but they are no longer included as -target-feature arguments in calls to cc1 by the clang driver. This is not the case when using -mcpu, for example.
I agree the end result will be the same assuming the information is consistent between the TargetParser and the backend's subtarget features, but I think it would be good to define the what's the clang driver's expected behaviour to avoid any inconsistencies in the future.

Ah I see, between the clang driver and cc1. Yes - I think in the past we were only caring about command line options like -march and -mcpu. In that case there is little difference in practice between adding the logic to the driver and adding it to clang proper. They both have the same effect in the end.
Nowadays we would like for attributes to be able to set architecture features too, as in function-multiversioning and using __attribute__((target("arch=.."))) attributes. When that becomes a consideration it is best for a lot of this logic to be handled in clang-proper, so it can be consistent between the two.

This revision was landed with ongoing or failed builds.Jan 16 2023, 8:58 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptJan 16 2023, 8:58 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript