[PATCH] D142388: [clang] Add builtin_nondet

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Be sure to add documentation for this to the language extensions page and mention the new builtin in the release notes.



================
Comment at: clang/include/clang/Basic/Builtins.def:658
 BUILTIN(__builtin_call_with_static_chain, "v.", "nt")
+BUILTIN(__builtin_nondet, "v.", "nt")
 
----------------
shafik wrote:
> erichkeane wrote:
> > Not a fan of the name in general, it doesn't really explain what is happening.  Perhaps `__builtin_nondeterministic_value` or something?  
> > 
> > I also wonder if others might have a better name :) 
> `__builtin_indeterminate_value` wdyt?
I think `__builtin_unspecified_value()` makes sense, as that's what you're getting back (there is a valid value, but you may get a different value on every call). I don't think `indeterminate` makes sense because that implies it may return trap values, and I'm guessing that's not behavior we want here (or am I wrong about that)?

Also, should this be usable within a constant expression? I would assume not; we should have a test case showing you can't use it in such a context.


================
Comment at: clang/include/clang/Basic/Builtins.def:658
 BUILTIN(__builtin_call_with_static_chain, "v.", "nt")
+BUILTIN(__builtin_nondet, "v.", "nt")
 
----------------
aaron.ballman wrote:
> shafik wrote:
> > erichkeane wrote:
> > > Not a fan of the name in general, it doesn't really explain what is happening.  Perhaps `__builtin_nondeterministic_value` or something?  
> > > 
> > > I also wonder if others might have a better name :) 
> > `__builtin_indeterminate_value` wdyt?
> I think `__builtin_unspecified_value()` makes sense, as that's what you're getting back (there is a valid value, but you may get a different value on every call). I don't think `indeterminate` makes sense because that implies it may return trap values, and I'm guessing that's not behavior we want here (or am I wrong about that)?
> 
> Also, should this be usable within a constant expression? I would assume not; we should have a test case showing you can't use it in such a context.
Why does this require custom typechecking?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142388