labrinea added subscribers: nickdesaulniers, t.p.northover, srhines. labrinea added a comment.
I wanted to clarify the chosen strategy as the desciption was perhaps not very informative. The are some instructions and system registers that are present in v8-a but not in v8-r, and so I am inclined to turn the `generic` cpu into the intersection of the two architecture profiles. The reasoning is to stay inline with the existing driver strategy: even when -march is specified on the command line clang passes -taget-cpu=generic to the backend, plus whatever subtarget features are implied by -march. The only exception to this rule seems to be AArch32 v8-r, where cortex-r52 is prefered over generic. This is an inconsistency and I wouldn't want to repeat the same for AArch64 (unless it's really necessary). That said my current approach will be breaking the current tools behavior: when the user only specifies the triple and not -march then they will be targeting the intersection, not v8-a. The impact is not expected to be significant as the missing instructions (smc, dcps3) were not being generated anyway. However if the two profiles significantly diverge in the future it might become a problem. There are some alternative solutions to this: - make the clang driver implicitly pass -march=armv8-a when only the triple is specified; then all the v8-a subtarget features will be enabled allowing smc, dcps3 and the system registers to be available (my preference) - leave the generic cpu as is (so that it means v8-a, not the intersection), and make the clang driver set -target-cpu with the default cpu for a given architecture (according to the Target Parser) when -march is specified; this change will also be breaking the current tools behavior though (middle ground option) - introduce a new `generic-r` cpu (or use cortex-r82) when setting -target-cpu, but only when -march=armv8-r, otherwise choose `generic` (least favorite option) I am adding a few people for visibility, requesting comments @t.p.northover @srhines @nickdesaulniers CHANGES SINCE LAST ACTION https://reviews.llvm.org/D110065/new/ https://reviews.llvm.org/D110065 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
