This is an archive of the discontinued LLVM Phabricator instance.

AMDGPU: Don't hard error on LDS globals in functions
ClosedPublic

Authored by arsenm on Mar 11 2020, 8:52 AM.

Details

Summary

Instead, emit a trap and a warning. We force inlining of this
situation, so any function where this happens should be dead as
indirect or external calls are not yet supported. This should avoid
erroring on dead code.

Diff Detail

Event Timeline

arsenm created this revision.Mar 11 2020, 8:52 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 11 2020, 8:52 AM
This revision is now accepted and ready to land.Mar 11 2020, 11:30 AM

What happens if user uses shared variable in a function marked with noinline? Will the function get inlined in kernel, or will the function not be inlined and ends up with a trap when called by a kernel? Thanks.

What happens if user uses shared variable in a function marked with noinline? Will the function get inlined in kernel, or will the function not be inlined and ends up with a trap when called by a kernel? Thanks.

Noinline will never be overridden, so it will emit a warning and codegen to a trap

So we will never be able to debug a HIP program compiled with -O0 where a device function uses shared variable since all functions are noinilne. This seems quite a restriction.

So we will never be able to debug a HIP program compiled with -O0 where a device function uses shared variable since all functions are noinilne. This seems quite a restriction.

I'm strongly opposed to clang using noinline at -O0. This should be stopped

So we will never be able to debug a HIP program compiled with -O0 where a device function uses shared variable since all functions are noinilne. This seems quite a restriction.

I'm strongly opposed to clang using noinline at -O0. This should be stopped

I will see if I can change that, at least for HIP.

So we will never be able to debug a HIP program compiled with -O0 where a device function uses shared variable since all functions are noinilne. This seems quite a restriction.

I'm strongly opposed to clang using noinline at -O0. This should be stopped

I will see if I can change that, at least for HIP.

The thread the pulls on is that optnone artificially requires noinline, another constraint I have a problem with