This is an archive of the discontinued LLVM Phabricator instance.

AMDGPU: Don't handle kernarg.segment.ptr in functions
ClosedPublic

Authored by arsenm on Mar 12 2020, 3:53 PM.

Details

Reviewers
rampitec
b-sumner
Summary

Just lower this to null. Pass implicitarg.ptr in its place in the
argument list.

Diff Detail

Event Timeline

arsenm created this revision.Mar 12 2020, 3:53 PM

I'm not aware of any valid explicit uses of this intrinsic by library or developer code, so this seems fine to me.

A trap would be better, we can easily spot it.

A trap would be better, we can easily spot it.

A trap would be better, we can easily spot it.

A trap isn’t particularly different from the null dereference if you try to actually use it. I was leaning more towards a compile time error

A trap would be better, we can easily spot it.

A trap would be better, we can easily spot it.

A trap isn’t particularly different from the null dereference if you try to actually use it. I was leaning more towards a compile time error

It is actually very different. A null pointer dereference means debugging, tracking the pointer, analyzing IR step by step until you see why was null emitted. A trap on the contrary is immediately visible in the ISA dump and immediately triggers the alarm, that compiler have spotted the code which should never been executed.

A trap would be better, we can easily spot it.

A trap would be better, we can easily spot it.

A trap isn’t particularly different from the null dereference if you try to actually use it. I was leaning more towards a compile time error

It is actually very different. A null pointer dereference means debugging, tracking the pointer, analyzing IR step by step until you see why was null emitted. A trap on the contrary is immediately visible in the ISA dump and immediately triggers the alarm, that compiler have spotted the code which should never been executed.

The trap adds extra complexity to the implementation since now the queue ptr needs to be passed to the function. This should probably be considered a backend internal intrinsic now, so I'm not sure it's worth the effort

rampitec accepted this revision.Mar 13 2020, 10:44 AM

A trap would be better, we can easily spot it.

A trap would be better, we can easily spot it.

A trap isn’t particularly different from the null dereference if you try to actually use it. I was leaning more towards a compile time error

It is actually very different. A null pointer dereference means debugging, tracking the pointer, analyzing IR step by step until you see why was null emitted. A trap on the contrary is immediately visible in the ISA dump and immediately triggers the alarm, that compiler have spotted the code which should never been executed.

A trap would be better, we can easily spot it.

A trap would be better, we can easily spot it.

A trap isn’t particularly different from the null dereference if you try to actually use it. I was leaning more towards a compile time error

It is actually very different. A null pointer dereference means debugging, tracking the pointer, analyzing IR step by step until you see why was null emitted. A trap on the contrary is immediately visible in the ISA dump and immediately triggers the alarm, that compiler have spotted the code which should never been executed.

The trap adds extra complexity to the implementation since now the queue ptr needs to be passed to the function. This should probably be considered a backend internal intrinsic now, so I'm not sure it's worth the effort

Sigh. OK, let's hope we will never have to debug it.

This revision is now accepted and ready to land.Mar 13 2020, 10:44 AM