This is an archive of the discontinued LLVM Phabricator instance.

AMDGPU: Verify subtarget specific builtins
ClosedPublic

Authored by arsenm on Feb 22 2016, 9:35 AM.

Details

Summary

Cleanup setup of subtarget features.

Diff Detail

Event Timeline

arsenm updated this revision to Diff 48701.Feb 22 2016, 9:35 AM
arsenm retitled this revision from to AMDGPU: Verify subtarget specific builtins.
arsenm updated this object.
arsenm added reviewers: tstellarAMD, echristo.
arsenm added a subscriber: cfe-commits.
echristo added inline comments.Feb 22 2016, 1:01 PM
lib/Basic/Targets.cpp
1795

Extra whitespace.

2010–2014

This is typically more of the "move the cpu checks down here" area from what you'd have above. Also you're not calling the target independent version of initFeatureMap - is that done on purpose?

arsenm added inline comments.Feb 22 2016, 2:48 PM
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.

echristo edited edge metadata.Mar 8 2016, 11:01 PM

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.
b) None of this code is connected to the backend at all. There's some disagreement as to what level the front end should connect to the backend in this way. It's probably better left for another day.
c) Yes, these functions are all part of handling features that can be set on a function, or are the defaults coming in via the driver.
d) They're separate, sadly, because I couldn't get them together in the time I spent rewriting it. Take a look at the comment at Targets.cpp:8086 for a bit more detail.
e) validateCpuSupports is only used in one case right now and that's for a particular builtin that's only supported on one target. Go ahead and ignore that for your purposes now, if you later want to support it we can talk about it.
f) I'm not sure why you care whether or not setFeatureEnabled is virtual, but we can discuss it if you'd like - and why you think it shouldn't be :)

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.

arsenm updated this revision to Diff 51636.Mar 25 2016, 7:59 AM
arsenm edited edge metadata.

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

echristo accepted this revision.Jun 7 2016, 2:45 PM
echristo edited edge metadata.

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.

This revision is now accepted and ready to land.Jun 7 2016, 2:45 PM
arsenm closed this revision.Jun 7 2016, 7:03 PM

r272091

test/CodeGenOpenCL/builtins-amdgcn.cl