[PATCH] D12937: [ARM] Handle +t2dsp feature as an ArchExtKind in ARMTargetParser.def

[Peter Smith via llvm-commits]

psmith added a subscriber: psmith.
psmith added a comment.

Hello,

I'm concerned we might be using T2DSP inappropriately on A class targets that do not support Thumb 2.

Context:
For the A profile the DSP extensions were introduced in ARM state only in the ARMv5TE architecture. They became available in Thumb2 with the ARMv6T2 architecture.   
For the M profile the DSP extensions were introduced in the v7E-M architecture.

My understanding is that T2DSP is defined as:
/// Some M architectures don't have the DSP extension (v7E-M vs. v7M)
def FeatureDSPThumb2 : SubtargetFeature<"t2dsp", "Thumb2DSP", "true",

  "Supports v7 DSP instructions in Thumb2">;

I think that using AEK_T2DSP to descibe DSP extensions for Architectures that do not support Thumb2 is not ideal. In effect the definition above has become (approximately):
/// Some architectures don't have the DSP extension
def FeatureDSPThumb2 : SubtargetFeature<"t2dsp", "Thumb2DSP", "true",

  "Supports DSP instructions in ARM and/or Thumb2">;

Given the above feature exists and on the assumption "t2dsp" can't be changed to a general FeatureDSP, I've not got any universally better suggestions right now.

A possibility would be to introduce:
/// Some A architectures don't have the DSP extension in ARM state (v5T vs. v5TE)
def FeatureDSPARM : SubtargetFeature<"armdsp", "ARMDSP", "true",

  "Supports DSP instructions in ARM">;

This is more accurate but would require adding "armdsp" and "t2dsp" to many A class processors.

Regards

Peter


http://reviews.llvm.org/D12937