[Bug target/104714] [nvptx] Means to specify any sm_xx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104714 Tom de Vries changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Tom de Vries --- Added march-map.
[Bug target/104714] [nvptx] Means to specify any sm_xx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104714 --- Comment #2 from CVS Commits --- The master branch has been updated by Tom de Vries : https://gcc.gnu.org/g:de0ef04419e90eacf0d1ddb265552a1b08c18d4b commit r12-7891-gde0ef04419e90eacf0d1ddb265552a1b08c18d4b Author: Tom de Vries Date: Tue Mar 29 10:32:13 2022 +0200 [nvptx] Add march-map Say we have an sm_50 board, and we want to run a benchmark using the highest possible march setting. Currently there's march=sm_30, march=sm_35, march=sm_53, but no march=sm_50. So, we'd need to pick march=sm_35. Likewise, for a test script that handles multiple boards, we'd need a mapping from native board sm_xx to march, which might have to be updated with newer gcc releases. Add an option march-map, such that we can just specify march-map=sm_50, and let the compiler map this to the appropriate march. The option is implemented as a list of aliases, such that we have a somewhat lengthy (17 lines in total): ... $ gcc --help=target ... -march-map=sm_30Same as -misa=sm_30. -march-map=sm_32Same as -misa=sm_30. ... -march-map=sm_87Same as -misa=sm_80. -march-map=sm_90Same as -misa=sm_80. ... This implementation was chosen in the hope that it'll be easier if we end up with some misa multilib. It would be nice to have the mapping list generated from an updated nvptx-sm.def, but for now it's spelled out in nvptx.opt. Tested on nvptx. gcc/ChangeLog: 2022-03-29 Tom de Vries PR target/104714 * config/nvptx/nvptx.opt (march-map=*): Add aliases. gcc/testsuite/ChangeLog: 2022-03-29 Tom de Vries PR target/104714 * gcc.target/nvptx/march-map.c: New test.
[Bug target/104714] [nvptx] Means to specify any sm_xx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104714 --- Comment #1 from Tom de Vries --- (In reply to Tom de Vries from comment #0) > [ FWIW, it would be great if we could simply specify -march=native, and have > gcc query the nvidia driver to see what board there is using > cuDeviceGetAttribute and CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MAJOR and > CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MINOR. And possibly handle the > situation of multiple boards by using the minimum. But, much more involved > to realize. ] Though, it might be better to handle this externally, so have a tool: ... $ cat test.c #include #include int compute_capability_major; int compute_capability_minor; int main (void) { cuInit(0); int num_devices; cuDeviceGetCount (_devices); for (int i = 0; i < num_devices; ++i) { CUdevice device; cuDeviceGet (, i); cuDeviceGetAttribute (_capability_major, CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MAJOR, device); cuDeviceGetAttribute (_capability_minor, CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MINOR, device); printf ("sm_%d%d\n", compute_capability_major, compute_capability_minor); } return 0; } ... that compiles like so: ... $ gcc test.c -I ~/cuda/11.6.0/include -lcuda -o a.out -g ... and prints: ... $ ./a.out sm_75 ... and then name the tool nvptx-print-native or some such and use: ... native=$(nvptx-print-native) $cc ... -march=$native ... in scripts.