Cleanup setup of subtarget features.
Details
Diff Detail
Event Timeline
lib/Basic/Targets.cpp | ||
---|---|---|
2010–2014 | Not sure what you mean exactly by "move the cpu checks down here". Do you mean setting all of the feature has* member variables should be moved out of the AMDGPUTargetInfo constructor + setCPU into here? That was not done on purpose. I'm pretty confused about what all of these functions are for. I kind of expected all of this to automatically work from the target's set of defined features known from the backend. There seem to be a set of functions for manually parsing user specified features on a function and for those implied by the subtarget. Why is initFeatureMap separate from handleTargetFeatures? initFeatureMap seems to be almost the same thing with the addition of the CPU features. It's not clear to me what the difference between hasFeature and validateCpuSupports is supposed to mean, or why setFeatureEnabled is virtual. |
Replied inline, I hope this is helpful :)
lib/Basic/Targets.cpp | ||
---|---|---|
2010–2014 | Attempting to answer your questions, I'm mostly going phrase by phrase :) a) Yes, I mean this. Most of these functions have few (or one) use and it is in Targets.cpp. (Don't worry about the ones outside of Targets.cpp for now, that's part of the function attribute code which was the cause of the cleanup (I promise it was) and refactoring I did, but doesn't affect clang initialization. |
Try to move more code into initFeatureMap.
I'm not sure how the booleans for features in the class are for now. X86 seems to have them, but it seems they are only used with user specified features? The only ones that matter right now don't depend on the subtarget, so I've left that in the constructor
Seems pretty reasonable. If I missed anything we can pick it up later.
-eric
lib/Basic/Targets.cpp | ||
---|---|---|
2010 | Means it was either passed in via -mcpu or is set on the function via an attribute. |
Extra whitespace.