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
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
