[PATCH] D97735: [Globals] Treat nobuiltin fns as maybe-derefined.

[Jeroen Dobbelaere via Phabricator via llvm-commits]

jeroen.dobbelaere added inline comments.


================
Comment at: llvm/include/llvm/IR/GlobalValue.h:147
+      // derefined.
+      return isInterposable() || isNobuiltinFnDef();
     }
----------------
fhahn wrote:
> jdoerfert wrote:
> > rsmith wrote:
> > > I don't think `nobuiltin` is relevant; I think what matters is whether the function is a builtin function. We have the same miscompile if we removed all the `builtin` / `nobuiltin` annotations from the IR generated for the PR49022 example, and this change does nothing to address that case.
> > So you are saying we can legally define our own `operator delete(void*) = _ZdlPv` without a `nobuiltin` attribute and that would still need to stop IPO from assuming it is the idealized version we all know and love?
> I think the problem is how would we detect that a given global value may be used with builtin semantics? 
> 
> Do frontends create function definitions for recognized builtins without `nobuiltin`? If frontends need to do so, can they add an attribute to indicate that this functions may be used with some builtin semantics?
> I think the problem is how would we detect that a given global value may be used with builtin semantics? 
> 
> Do frontends create function definitions for recognized builtins without `nobuiltin`? If frontends need to do so, can they add an attribute to indicate that this functions may be used with some builtin semantics?

How can frontends know about 'future builtins' ? Should they already annotate all functions as 'nobuiltin' (except for the known builtins).
What about the following:   https://www.godbolt.org/z/To69x5
A 'c' program where we happen to use the encoded 'new/delete' names. I don't think llvm should optimize those.





Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97735