[PATCH] D79580: AMDGPU: Don't assert on unknown address spaces

[Brian Sumner via Phabricator via llvm-commits]

b-sumner added a comment.

In D79580#2026301 <https://reviews.llvm.org/D79580#2026301>, @arsenm wrote:

> In D79580#2026263 <https://reviews.llvm.org/D79580#2026263>, @rampitec wrote:
>
> > In D79580#2026107 <https://reviews.llvm.org/D79580#2026107>, @arsenm wrote:
> >
> > > In D79580#2025743 <https://reviews.llvm.org/D79580#2025743>, @rampitec wrote:
> > >
> > > > In D79580#2025725 <https://reviews.llvm.org/D79580#2025725>, @arsenm wrote:
> > > >
> > > > > In D79580#2025685 <https://reviews.llvm.org/D79580#2025685>, @rampitec wrote:
> > > > >
> > > > > > How do we get these address spaces? I'd rather error out.
> > > > >
> > > > >
> > > > > You can use __attribute__((address_space)) or hand write IR. We should not error on valid IR. Someday a frontend may wish to track special information with a custom address space number, which we can handle as a global alias similar to how x86 accepts any arbitrary address space
> > > >
> > > >
> > > > It sounds dangerous. An unknown address space has unknown semantics. How could we assume anything about it?
> > >
> > >
> > > It doesn't have unknown semantics, it has target defined semantics. We can interpret them however we want. At a minimum any pointer computation on the values should work, even if load and store don't select
> >
> >
> > Is there any particular motivation to add this support?
>
>
> Just generally making a best effort attempt to handle any IR that passes the verifier. We already try to handle these in a variety of other places the same way, and theoretically someone could want to use it.


That sounds reasonable.  I can think of a situation where it would enable certain investigations.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79580/new/

https://reviews.llvm.org/D79580