pasaulais wrote: > > @arsenm That makes sense, I don't think MMRA fits the fine-grained use case > > either. Does that mean we can stick with the approach from this PR? > > @b-sumner mentioned there was another similar approach being worked on. > > Something like this, but the naming and direction of this PR is backwards. > The default should be assume fine grained memory is possible. We also have > another orthogonal bit we need to track in addition to fine grained memory. I > was envisioning this as a single integer interpreted as bitfields of the two, > but this uses different key:value metadata pairs. It should be named > "amdgpu.no.something" to assert the operation doesn't access fine grained
@arsenm I agree that the default should be assuming fine-grained is possible. My thinking behind the original naming and direction was not wanting to introduce an unexpected performance regression by default. I'm happy for both to be changed, and this patch being rebased on top of https://github.com/llvm/llvm-project/pull/85052 once it is merged. One oustanding question for me is, although outside of the scope of this PR, how will the original 'no-unsafe-fp' option fit in the new metadata node in terms of constraints? Would it imply a new constraint or be covered by `no_fine_grained` and `no_remote`? https://github.com/llvm/llvm-project/pull/69229 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
