On 11/2/20 9:03 AM, Patrick Palka wrote:
On Tue, 27 Oct 2020, Patrick Palka wrote:
The adoption of P2104 means we can memoize the result of satisfaction
indefinitely and no longer have to clear the satisfaction caches on
various events that would affect satisfaction. To that end, this patch
removes clear_satisfaction_cache and adjusts its callers appropriately.
This provides a massive reduction in compile time and memory use in some
cases. For example, on the libstdc++ test std/ranges/adaptor/join.cc,
compile time and memory usage drops nearly 75%, from 7.5s/770MB to
2s/230MB, with a --enable-checking=release compiler.
[ This patch depends on
c++: Check constraints only for candidate conversion functions.
Without it, many of the libstdc++ range adaptor tests fail due to
us now indefinitely memoizing a bogus satisfaction result caused by
checking the constraints of a conversion function when we weren't
supposed to, which led to a "use of foo_view::end() before deduction
of auto" SFINAE error. This went unnoticed without this patch because
by the time we needed this satisfaction result again, we had cleared
the satisfaction cache and finished deducing the return type of
foo_view::end(), so on subsequent tries we computed the correct
satisfaction result. ]
With the library-side workaround r11-4584 for the range adaptor test
failures now committed, the mentioned frontend patch about candidate
conversion functions is no longer a prerequisite (and was not we want
anyway).
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk (pending approval of the prerequisite patch)? Also tested on
cmcstl2 and range-v3.
Now successfully bootstrapped and regtested on top of r11-4584, and also
tested on cmcstl2 and range-v3. Does this look OK for trunk?
For me, this patch broke the view.join test in cmcstl2. Are you not
seeing that?
Jason
