This is an archive of the discontinued LLVM Phabricator instance.

__builtin_constant_p should consider the parameter of a constexpr function as constant
Needs ReviewPublic

Authored by ogoffart on Jul 10 2017, 1:00 AM.

Details

Summary

This allows to do something like:

constexpr int func(int x) {
  return __builtin_constant_p(x) ? compute_constexpr(x) : compute_runtime(x);
}

This kind of code is accepted by GCC since GCC 4.8.

The problem was that EvaluateBuiltinConstantP was discarding the EvalInfo and its frames. So just keep the EvalInfo

Diff Detail

Event Timeline

ogoffart created this revision.Jul 10 2017, 1:00 AM
joerg added a subscriber: joerg.Jul 12 2017, 6:28 AM

What if the constexpr function is called with in a non-constexpr context, e.g. with a random global variable as argument?

EricWF added a subscriber: EricWF.Jul 12 2017, 6:45 AM

What if the constexpr function is called with in a non-constexpr context, e.g. with a random global variable as argument?

__builtin_constant_p will still return false in this case, contrary to gcc (whose behavior actually depends on the optimization level).

I think if we really want to get the exact gcc behavior, we need to mix it with the optimizer and generate some LLVM intrinsics. But what I was interested on with this patch is at least get a closer behavior as GCC in a constexpr context

See https://bugs.llvm.org/show_bug.cgi?id=4898 for more discussion of __builtin_constant_p in LLVM vs. gcc.

Thanks for the link to the bug report.
This patch mostly address the evaluation within a constexpr, which is orthogonal to the changes in the backend suggered in that bug report.

Is there any objections for this patch?