Hi Prathamesh! On 2024-08-08T06:46:25-0700, Andrew Pinski <pins...@gmail.com> wrote: > On Thu, Aug 8, 2024 at 6:11 AM Prathamesh Kulkarni > <prathame...@nvidia.com> wrote: >> After differing NUM_POLY_INT_COEFFS fix for AArch64/nvptx offloading, the >> following minimal test:
First, thanks for your work on enabling this! I will say that I had the plan to re-engage with Nvidia to hire us (as initial implementors of GCC/nvptx offloading) to make AArch64/nvptx offloading work, but now that Nvidia has its own GCC team, that's great that you're able to work on this yourself! :-) Please CC me for GCC/nvptx issues for (at least potentially...) faster response times. >> compiled with -fopenmp -foffload=nvptx-none now fails with: >> gcc: error: unrecognized command-line option '-m64' >> nvptx mkoffload: fatal error: ../install/bin/gcc returned 1 exit status >> compilation terminated. Heh. Yeah... >> As mentioned in RFC email, this happens because >> nvptx/mkoffload.cc:compile_native passes -m64/-m32 to host compiler >> depending on whether >> offload_abi is OFFLOAD_ABI_LP64 or OFFLOAD_ABI_ILP32, and aarch64 backend >> doesn't recognize these options. >> >> Based on your suggestion in: >> https://gcc.gnu.org/pipermail/gcc/2024-July/244470.html, >> The attached patch generates new macro HOST_MULTILIB derived from >> $enable_as_accelerator_for, and in mkoffload.cc it gates passing -m32/-m64 >> to host_compiler on HOST_MULTILIB. I verified that the macro is set to 0 for >> aarch64 host (and thus avoids above unrecognized command line option error), >> and is set to 1 for x86_64 host. >> >> Does the patch look OK ? > > Note I think the usage of the name MULTILIB here is wrong because > aarch64 (and riscv) could have MUTLILIB support just the options are > different. I also think the proposed patch is not quite the right hammer for the issue at hand. > For aarch64, it would be -mabi=ilp32/-mabi=lp64 (riscv it > is more complex). > > This most likely should be something more complex due to the above. Right. > Maybe call it HOST_64_32 but even that seems wrong due to Aarch64 > having ILP32 support and such. Right. > What about HOST_64ABI_OPTS="-mabi=lp64"/HOST_32ABI_OPTS="-mabi=ilp32" > but I am not sure if that would be enough to support RISCV which > requires two options. So, my idea is: instead of the current strategy that the host 'TARGET_OFFLOAD_OPTIONS' synthesizes '-foffload-abi=lp64' etc., which the 'mkoffload's then interpret and re-synthesize '-m64' etc. -- how about we instead directly tell the 'mkoffload's the relevant ABI options? That is, 'TARGET_OFFLOAD_OPTIONS' instead synthesizes '-foffload-abi=-m64' etc., which the 'mkoffload's can then readily use. Could you please give that a try, and/or does anyone see any issues with that approach? And use something like '-foffload-abi=disable' to replace the current: /* PR libgomp/65099: Currently, we only support offloading in 64-bit configurations. */ if (offload_abi == OFFLOAD_ABI_LP64) { (As discussed before, this should be done differently altogether, but that's for another day.) Grüße Thomas
