Bernd Edlinger <bernd.edlin...@hotmail.de> writes:
> On 11/15/16 13:21, Richard Sandiford wrote:
>> Bernd Edlinger <bernd.edlin...@hotmail.de> writes:
>>> Hi!
>>>
>>> The genattrtab build-tool uses way too much memory in general.
>>> I think there is no other build step that uses more memory.
>>>
>>> On the currently trunk it takes around 700MB to build the
>>> ARM latency tab files. I debugged that yesterday
>>> and found that this can be reduced to 8MB (!). Yes, really.
>>>
>>> So the attached patch does try really hard to hash and re-use
>>> all ever created rtx objects.
>>>
>>> Bootstrapped and reg-tested on x86_64-pc-linux-gnu and ARM.
>>> Is it OK for trunk?
>>
>> Just to check: does this produce the same output as before?
>> And did you notice any difference in the time genattrtab
>> takes to run?
>>
>
> The run time was in the range of 24-25s, with and without the patch.
>
> However the tables are a bit different, although that seems only to be
> w flaw with the ATTR_CURR_SIMPLIFIED_P which is now re-used when a
> matching rtx was found in the hash. As I said, the generated functions
> do really work, probably because just a few simplifications are missing.
>
> So it looks like I need to clear the ATTR_CURR_SIMPLIFIED_P on re-used
> binary ops. That I found out just by try-and-error. I can say that now
> the generated functions are exactly identical for i386, arm and mips.
> The memory and the run time did not change due to this re-hashing.
OK, thanks for checking.
>> ATTR_PERMANENT_P is supposed to guarantee that no other rtx like it exists,
>> so that x != y when x or y is "permanent" implies that the attributes
>> must be different. This lets attr_equal_p avoid a recursive walk:
>>
>> static int
>> attr_equal_p (rtx x, rtx y)
>> {
>> return (x == y || (! (ATTR_PERMANENT_P (x) && ATTR_PERMANENT_P (y))
>> && rtx_equal_p (x, y)));
>> }
>>
>> Does the patch still guarantee that?
>>
>
> Hmm, I see. I expected that ATTR_PERMANENT_P means more or less,
> that it is in the hash table. I believe that a long time ago, there
> was a kind of garbage collection of temporary rtx objects, that needed
> to be copied from the temporary space to the permanent space, after
> the simplification was done. And then all temporary objects were
> just tossed away. But that was long before my time. Today
> everything is permanent, that is why the memory usage is unbounded.
>
> But I can fix that, by only setting ATTR_PERMANENT_P on the hashed
> rtx when both sub-rtx are also ATTR_PERMANENT_P.
>
>
> How does that new version look, is it OK?
OK. Thanks for doing this, certainly an impressive headline number :-)
Richard
