On Wed, Feb 03, 2016 at 06:07:25PM +0100, Bernd Schmidt wrote:
> On 02/02/2016 09:59 AM, Jakub Jelinek wrote:
>
> >I wonder if it wouldn't be better to pass around some structure, containing
> >for the common case fixed size cache and perhaps fall back to hash_map if
> >there are more calls to cac
On 02/02/2016 09:59 AM, Jakub Jelinek wrote:
I wonder if it wouldn't be better to pass around some structure, containing
for the common case fixed size cache and perhaps fall back to hash_map if
there are more calls to cache than that. Plus perhaps a recursion depth, so
that we avoid other path
On Tue, Feb 02, 2016 at 12:50:39AM +0100, Bernd Schmidt wrote:
> On 02/01/2016 09:34 PM, Jakub Jelinek wrote:
> >On the following testcase we completely uselessly consume about 5.5GB
> >of RAM and lots of compile time. The problem is the code to avoid
> >exponential behavior of nonzero_bits/num_si
On 02/01/2016 09:34 PM, Jakub Jelinek wrote:
On the following testcase we completely uselessly consume about 5.5GB
of RAM and lots of compile time. The problem is the code to avoid
exponential behavior of nonzero_bits/num_sign_bit_copies on binary
arithmetics rtxes, which causes us to recurse ev
On 02/01/2016 01:34 PM, Jakub Jelinek wrote:
Hi!
On the following testcase we completely uselessly consume about 5.5GB
of RAM and lots of compile time. The problem is the code to avoid
exponential behavior of nonzero_bits/num_sign_bit_copies on binary
arithmetics rtxes, which causes us to recur
