[PATCH] D157451: [AMDGPU] Do not deduce access qualifiers from IR attributes

Changpeng Fang via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 9 16:07:41 PDT 2023


cfang added inline comments.


================
Comment at: llvm/test/CodeGen/AMDGPU/hsa-metadata-deduce-ro-arg-v3.ll:26
 }
 
 !0 = !{i32 1, i32 1}
----------------
rampitec wrote:
> cfang wrote:
> > rampitec wrote:
> > > arsenm wrote:
> > > > cfang wrote:
> > > > > arsenm wrote:
> > > > > > cfang wrote:
> > > > > > > arsenm wrote:
> > > > > > > > This looks like lost test coverage, need to test the access of the metadata
> > > > > > > Under V3, if the access is default, it won't print out "default", (will not print out the access qualifier at all).
> > > > > > > 
> > > > > > > But I am curious because "noalias readonly %in", why the access is not "readonly"? Does it mean the original access qualifier got lost? 
> > > > > > the point of this is introspection of the source program, not the actual properties. if someone defines something as readwrite but is only ever read, the optimizer can conclude it's readonly even though it wasn't declared that way
> > > > > Under V3 or above, it is designed NOT to print out the access qualifier if it is "default". 
> > > > > Do you want to CHECK-NOT for :access" for the default?
> > > > > 
> > > > > 
> > > > > 
> > > > -NEXT checks are safer than -NOT
> > > Right, this can be deduced and had quite positive performance impact on some kernels.
> > It seems we are using the same AccQual field for two purposes: 1) optimization, 2) get_kernel_arg_info.AccessQualifier, and 
> > the second one is expected from  getMetadata("kernel_arg_access_qual")
> This is the same thing, one is because developer marked it (and language allowed this marking), another because we were able to prove it from compiler. Net impact is still the same, RT may omit copying memory before every dispatch.
We are seeing a conformance test failure with test_api get_kernel_arg_info.
The test expects access qualifier to be access_none for any kernels other than image and pipes.
Do you think the checks from this test are not reasonable?  


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

https://reviews.llvm.org/D157451



More information about the llvm-commits mailing list