This is an archive of the discontinued LLVM Phabricator instance.

[openmp] Fix flang detection for offloading test
ClosedPublic

Authored by elmcdonough on Aug 22 2023, 1:44 PM.

Details

Summary

This patch fixes the flang detection in the openmp fortran offloading test.

Diff Detail

Event Timeline

elmcdonough created this revision.Aug 22 2023, 1:44 PM
Herald added a project: Restricted Project. · View Herald Transcript
elmcdonough requested review of this revision.Aug 22 2023, 1:44 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 22 2023, 1:44 PM

This change works for me, so the test is run and fails with:

ld.lld: error: undefined symbol: increment_at
>>>> referenced by /tmp/lit-tmp-hsj2_6gq/basic_array.c.tmp.amdgcn-amd-amdhsa.gfx90a-465f86.o:(__omp_offloading_802_ae2379e_increment_array_l17)
>>>> referenced by /tmp/lit-tmp-hsj2_6gq/basic_array.c.tmp.amdgcn-amd-amdhsa.gfx90a-465f86.o:(__omp_offloading_802_ae2379e_increment_array_l17)
clang: error: ld.lld command failed with exit code 1 (use -v to see invocation)
/home/jsjodin/git/trunk/llvm-project/build/./bin/clang-linker-wrapper: error: 'clang' failed
clang: error: linker command failed with exit code 1 (use -v to see invocation)

error: command failed with exit status: 1

This change works for me, so the test is run and fails with:

ld.lld: error: undefined symbol: increment_at
>>>> referenced by /tmp/lit-tmp-hsj2_6gq/basic_array.c.tmp.amdgcn-amd-amdhsa.gfx90a-465f86.o:(__omp_offloading_802_ae2379e_increment_array_l17)
>>>> referenced by /tmp/lit-tmp-hsj2_6gq/basic_array.c.tmp.amdgcn-amd-amdhsa.gfx90a-465f86.o:(__omp_offloading_802_ae2379e_increment_array_l17)
clang: error: ld.lld command failed with exit code 1 (use -v to see invocation)
/home/jsjodin/git/trunk/llvm-project/build/./bin/clang-linker-wrapper: error: 'clang' failed
clang: error: linker command failed with exit code 1 (use -v to see invocation)

error: command failed with exit status: 1

Yeah, that test fails at the moment. Right now it seems that increment_at isn't registered as a symbol in the LLVM bitcode for the embedded object. I can confirm that this used to work, but I'm still trying to figure out why it doesn't anymore.

Fixes the actual test. Adding !$omp declare target to the offloaded function prevents the OMPFunctionFiltering pass from optimizing it out. I'm not sure if we want public functions to be hidden from object files targeting GPUs, but I think that might be outside the scope of this patch.

jsjodin accepted this revision.Aug 29 2023, 8:32 AM

Fixes the actual test. Adding !$omp declare target to the offloaded function prevents the OMPFunctionFiltering pass from optimizing it out. I'm not sure if we want public functions to be hidden from object files targeting GPUs, but I think that might be outside the scope of this patch.

LGTM, the test passes for me.

I'm not sure what the correct behavior is. The standard says:
"If a procedure is explicitly or implicitly referenced in a target construct that does not specify a device clause in which the ancestor device-modifier appears then that procedure is treated as if its name had appeared in an enter clause on a declare target directive"
It doesn't say it has to be in the same compilation unit, but it also doesn't seem unreasonable to have to specify declare target if it is outside the compilation unit. @jdoerfert, do you know correct behavior is?

This revision is now accepted and ready to land.Aug 29 2023, 8:32 AM
This revision was automatically updated to reflect the committed changes.

This unfortunately picks up a random flang-new, if there is one on the path.