On 04/12/2016 04:58 PM, Nathan Sidwell wrote:
Well, I had a patch all ready, but when writing it up, I discovered the
logic behind comment #26 is wrong. Specifically, Jason's proto-patch
makes the fn_copy_table GCable, but keeps the constexpr_call_table
GC-deletable. The logic is that if we need to recreate a particular
constexpr call, we'll have a body available so not need to do another
copy. But consider a constexpr such as:
constexpr int Foo (int i) { return i ? Foo (i - 1) : 0; }
Then the following evaluations:
Foo (0)
<possible GC>
Foo (1)
If the GC does not happen, we'll have cached the evaluation of 'Foo(0)',
and so not need to reevaluate it during the 'Foo(1)' call. The
evaluation of 'Foo(1)' will use the single cached body of Foo for it's
own evaluation, so no additional cloning will happen.
However, if the GC does happen, we'll need to evaluate 'Foo(0)' again,
but there'll be no cached body of Foo available (it being in use for
'Foo(1)'). So we will observe a UID change.
I think that means the constexpr_call_table must be preserved too.
Something along the lines of the size checking I posted yesterday? (but
with the GTY stuff done better).
I think for now let's just make it non-deletable as well and not worry
about trying to keep it from growing too big.
Jason
