https://github.com/nikic requested changes to this pull request.
> That doesn't have to be an either/or question. Both approaches can be made to > work side-by-side, particularly while getting real-world testing of the > impact. I do not see the value in making multiple approaches work side-by-side. We should settle on one design and implement that. If you'd like to evaluate real-world impact of different approaches, that should happen before landing something upstream. > This approach seemed to already be used by many other intrinsics (e.g. > lifetime, var_annotation, assume, invariant), while the metadata approach > seemed less common and less reliable (it actually is pre-existing, but isn't > fully implemented currently). This approach is used by other intrinsics because they *must* use intrinsics for semantic reasons. For lifetime intrinsics and assumes the position in the program matters. For invariant intrinsics, depending on which one's you're talking about, either the position in the program, or being part of the use-def chain matters (as they effectively return pointers with new provenance). The metadata approach *is* widely used in the context where it is appropriate (like for aliasing metadata). In this case, you want to encode something that is purely a property of the alloca, not a property of some program position, or the property of some use of the alloca. As such, the property should be encoded directly on the alloca, as metadata. https://github.com/llvm/llvm-project/pull/183623 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
