spavloff wrote: > > > If you're going to use that approach, though, why change IRBuilder? > > > > IRBuilder methods CreateCall add memory effect attributes to the FP > > operation calls. > > I mean, it doesn't matter what attributes the call has because > getFloatingPointMemoryEffects() will override whatever we specify.
Essentially you are right. The changes to IRBuilder has been removed. This makes it harder to identify side effects from listing in some cases, but that is not important for the current model, where side effect are determined by function attributes only. > > > > This change fixes the use case that is now not allowed. The existing > > strictfp implementation based on constrained functions is not changed. > > Clang does not use the proposed model for code generation. So these changes > > must be invisible to users. > > Sure, but people writing their own frontends could stumble over this. If the > whole series lands quickly, this might not be an issue, but I'd prefer to > plan for the case where a later patch in the series gets stuck for whatever > reason. I have put back the paragraph in the documentation, which states that all functions must be constrained, may be it is enough. Compiler with this patch applied would behave exactly as it does without it from the user's viewpoint, - currently the compiler does not dignose using non-constrained intrinsics in strictfp functions. https://github.com/llvm/llvm-project/pull/188297 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
