[PATCH] D136515: [builtins] Add __builtin_assume_separate_storage.

Thu Apr 27 00:38:43 PDT 2023

OfekShilon added subscribers: kosarev, OfekShilon.
OfekShilon added inline comments.

================
Comment at: clang/docs/LanguageExtensions.rst:2393
+particular object (so for example, it's never correct to call this function
+passing the addresses of fields in the same struct, elements of the same array,
+etc.).
----------------
bruno wrote:
> davidtgoldblatt wrote:
> > bruno wrote:
> > > Not necessarily a blocker, but it seems like some of these things you mention can actually be caught by diagnostics without too much effort? Any plans to add them?
> > I hadn't planned to (at least in the short term). Practically I expect uses of this to be mostly backed out from looking at bad assembly (this is the way I've been using it so far in experimentation). You wouldn't generally expect people to want to try to express "these two struct fields don't alias" and so on because alias analysis can already handle those cases fairly well.
> > 
> > My inclination would be to wait on the diagnostics until we see if it's a real problem, but I'm not strongly opposed if you'd really like them in v1. (Although in that case I'll probably bug you for some help with where / how to put the diagnostics).
> > My inclination would be to wait on the diagnostics until we see if it's a real problem
> 
> Sounds fair! Feel free to bug me when/if you decide to explore that route.
+2c: as of today tbaa *doesn't* handle well aliasing of two struct fields. There was some work to mitigate it by @kosarev (https://reviews.llvm.org/D41539) but it is still hidden behind a `-new-struct-path-tbaa` switch.   Example: https://godbolt.org/z/xPMzfea8W

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136515