[cfe-commits] [Patch 4 of 5] Proposed fix for PR12850

Andy Gibbs andyg1001 at hotmail.co.uk
Wed Sep 5 23:59:44 PDT 2012


On Wednesday, September 05, 2012 7:06 PM, Matthieu Monrocq wrote:
> On Wed, Sep 5, 2012 at 3:21 AM, Richard Smith wrote:
>> [...snip...]
>> This still seems like it could lead to a flaky compilation experience
>> (we hit the limit if we include a.h then b.h, but not if we include
>> them in the other order). This problem already exists for templates,
>> but I suspect it'll be worse for constexpr, since I would expect deep
>> recursion to occur more often. Essentially, I would like the caching
>> to be *entirely* undetectable (other than in performance).
>
> I guess the depth of the memoized expression could be added to the cache
> entry, this way whether the value was cached or the compiler recursively
> compute down to the bottom not does not affect whether the code compiles.

Indeed, I think this is the only way and have implemented it so in my
branch, but as a warning rather than an error.  I appreciate this is not
entirely undetectable as required by Richard, but is close enough if made
'DefaultError', and then can be disabled, as required, by the user (after
all, it is not *actually* recursing).  I'd personally rather it this way,
since careful pre-caching actually gives the programmer a way around the
problems of recursion depth...

On Wed, Sep 5, 2012 at 3:21 AM, Richard Smith wrote:
> Some part of the problem here is that APValue is a terrible format for
> long-term storage of constant values. I think we could get around a 5x
> reduction in the memory usage of APValues by replacing the
> representation with something denser. (I had a patch for this out for
> review ~9 months ago, but it'll take quite a bit of work to get it to
> apply cleanly to trunk...)

Richard, I'd be interested to see this patch -- maybe I can merge it to
trunk for you?  A 5x memory improvement would certainly be advantageous!

I've gone through your other comments and most of it is ok.  I'm looking
into FoldingSet/BumpPtrAllocator, but this will take a little while as
I am not able to devote much time to all of this at present.  I hope to
get something new posted early next week, as time permits, and I'll
address your points then...

Thanks
Andy





More information about the cfe-commits mailing list