yxsamliu wrote: > > @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 #85052 > > once it is merged. > > The opting for fast-and-maybe-broken by default needs to be a frontend > decision (i.e. the language can choose to add the metadata to all atomics). I > believe @yxsamliu is going to be working on the frontend half which will > preserve the HIP behavior > > > 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`? > > I believe we need an additional piece of metadata (which I have another draft > for) to express the relaxable floating point. We can express the > unsafe-fp-math option with the 2 combined, and then can drop the old IR > attribute
Will the metadata for unsafe-fp-atomics also be controlled by the pragma that controls the no-fine-grained and no-remote metadata? e.g. something like ``` #pragma clang atomics begin no-fine-grained(on) no-remote(on) unsafe-fp(on) ``` 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
