On Fri, Feb 14, 2014 at 3:50 AM, dxq <ziya...@163.com> wrote:
> Richard Biener-2 wrote
>> On Sat, Feb 8, 2014 at 8:29 AM, dxq &lt;
>
>> ziyan01@
>
>> &gt; wrote:
>>> hi all,
>>>
>>> We found that gcc would run out of memory on Windows when compiling a
>>> *big*
>>> function (100000 lines).
>>>
>>> More investigation shows that gcc crashes at the function
>>> *compute_avail*,
>>> in tree-fre pass.  *compute_avail* collects information from basic
>>> blocks,
>>> so memory is allocated to record informantion.
>>> However, if there are huge number of basic blocks,  the memory would be
>>> exhausted and gcc would crash down, especially for Windows PC, only 2G or
>>> 4G
>>> memory generally. It's ok On linux, and *compute_avail* allocates *2.4G*
>>> memory. I guess some optimization passes in gcc like FRE didn't consider
>>> the
>>> extreme
>>> case.
>>
>> This was fixed for GCC 4.8, FRE no longer uses compute_avail (but PRE
>> still does).
>> Basically GCC 4.8 should (at -O1) compile most extreme cases just fine.
>>
>> Richard.
>
> hi, Richard,
>
> More  investigation shows that
> 1, loop related passes take more compiling time and memory, especially
> pass_rtl_move_loop_invariants, lim,
>   and at least lim on tree will impact a lot to the following passes.
> 2, ira will take more than 20g memory in function *create_loop_tree_nodes*,
> because ira chooses 'mixed'
>   or 'all' region when optimize level.
> 3, sms pass always creats ddgs for all loops in compiled function, then does
> sms optimization for all loops,
>   and finally frees ddgs. If there are huge number of loops, sms may crash
> when creating ddgs because of
>   running out of memory.
>
> The passes above , should someone confirm about memory pressure problem?

What compiler version did you check?  I think that 4.8 has improvements
for 1. and 2. (SMS is unmaintained).  Note that we only spent time to
make -O1 behave sanely with extremely large functions.

Finally I'd suggest you open a bugreport and attach a testcase to it
that exposes the issues you list.

Richard.

> Thanks for your reply!
>
> danxiaoqiang
>
>
>
> --
> View this message in context: 
> http://gcc.1065356.n5.nabble.com/FRE-may-run-out-of-memory-tp1009578p1011035.html
> Sent from the gcc - patches mailing list archive at Nabble.com.

Reply via email to