[PATCH] D15746: Normalize the features string in SubtargetFeatures::getFeatureBits

[Eric Christopher via llvm-commits]

echristo added a comment.

I think canceling out may be the wrong way here.

There's a chain of thought here that changes in the middle, let's go through how I was thinking and then rethinking:

Seeing this string:

+fullfp16,-fp-armv8,+fp-armv8,+neon

and knowing that fp-armv8 is a "lower level" fp than fullfp16 I'd expect that at the end we'd have fp-armv8 and neon turned on. Similarly to how if you passed the x86 equivalent on the command line:

-msse4.2 -mno-sse2 -msse3

on the command line and get:

"target-features"="+fxsr,+mmx,+sse,+sse2,+sse3,-aes,-avx,-avx2,-avx512bw,-avx512cd,-avx512dq,-avx512er,-avx512f,-avx512pf,-avx512vl,-f16c,-fma,-fma4,-pclmul,-sha,-sse4.1,-sse4.2,-sse4a,-ssse3,-xop,-xsave,-xsaveopt"

which turns off everything sse2 and below and then turns on eveything up to sse3.

OK, that almost makes sense, however:

As a side, but important, note: I was going to use -mno-sse3 -msse3 as part of this example. It appears that the front end currently will take that as a last one wins and ignore the -mno-sse3. What would happen in your testcase if it were -, -, +? Last one wins?

Do we want last one wins here? Do we want all pairs to be merged and the one that's not a pair gone? Before we handle earlier ones? Ultimately I think we might want to assume that canonicalization has happened before we get to this point, i.e. maybe even disallow attribute strings that turn off features that were explicitly turned on earlier (not implicitly mind).

At any rate, thoughts?

:)

-eric


http://reviews.llvm.org/D15746