This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Whole program optimization and functions-only-called-once.


On Sat, Nov 21, 2009 at 6:36 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> Jan Hubicka wrote:
>>>> Toon Moene wrote:
>>>>
>>>>
>>>>> Jan Hubicka wrote:
>>>>>
>>>>>> :) It would be nice to know what caused the OOM. ?Is just one of
>>>>>> passes exploding
>>>>>> on presence of very large bodies?
>>>>>>
>>>>> I'll try to figure this out over the weekend (sorry, don't have
>>>>> more ?spare time).
>>>>>
>>>>> It's most probably a single pass, because the memory requirements
>>>>> kept ?creeping up to 12.5 Gbytes from 10, slowly increasing all the
>>>>> time over several minutes.
>>>>>
>>>> Here are the tracebacks from gdb attached to the lto1 process, while
>>>> it ?was expanding from 7 to 12 Gb:
>>>>
>>>
>>> Hopefully Vladimir will know answer here. ?Do you have any idea how many BBs
>>> and loops are in the large function?
>>>
>>>
>> I saw some functions which could have slowed down regional IRA a lot.
>> For example, a small function with 50 loops one after another.
>> Therefore IRA has already code (decreasing # of regions/loops for
>> consideration) to deal with the situation.
>
> I know little about weather prediction, but as usual simulation I would not
> expect it to have very deep loop nests. Toon, would be possible to have loop tree
> of the function in question?
>>
>> The worst what I saw a few years ago. ?One customer system generated
>> functions with 100K blocks and >1M pseudos. ? But fortunately they
>> started to split the code into several functions.
>
> What about the following patch that avoid ineffectivity of the loop exists
> enumerating code? Or is IRA enumerating exists in every loop just once during
> the analysis?

I think Tom patched GCC to inline every called-once function into a gigantic
main function and the ineffiency is not from recording exit edges but from
allocating the IRA bitmaps for each loop in advance (compared to for
BBs where we seem to set them simply to NULL).

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]