Re: How can I generate a new function at compile time?

[Benedikt Huber <benedikt dot huber at theobroma-systems dot com>]

I have not found out why the assertion is violated, yet.
However I noticed that the original function disappears somehow between
the passes pass_ipa_comdats and pass_fixup_cfg.
By that I mean that the function appears from the dump files.
These passes run several passes after the outlining pass.
Between the outlining pass and pass_ipa_comdats both functions
(the generated and the original with the call to the generated) are printed.
I do not know whether this has anything to do with the assertion but it
seems strange.
Do you have any guess why this happens?

Thank you,
Benedikt

On 28 May 2014, at 15:50, Richard Biener <richard.guenther@gmail.com> wrote:

> On Wed, May 28, 2014 at 3:28 PM, Benedikt Huber
> <benedikt.huber@theobroma-systems.com> wrote:
>> I ported the pass to the fsf trunk. It is built with —enable-checking.
>> The patch applied with no changes and also the behaviour is the same.
>> So I probably mess up the cfg somehow.
>> Can you suggest any strategy for finding the problem that I could use?
>> 
>> /home/bhuber/sandbox/fsf/install/bin/gcc -O3 -c -fdump-tree-all-details -fdump-ipa-all-details -fdump-rtl-all-details -fno-ipa-cp -fnop-pass -funinline-innermost-loops -Wall -Wextra /home/bhuber/sandbox/try/outline.c
>> /home/bhuber/sandbox/try/outline.c: In function '_GLOBAL__N_bar':
>> /home/bhuber/sandbox/try/outline.c:3:1: internal compiler error: in purge_dead_edges, at cfgrtl.c:3179
>> bar (int s, int r, unsigned * t, int * k, int * p, int * l)
>> ^
>> 0x681195 purge_dead_edges(basic_block_def*)
>>        ../../src/gcc/cfgrtl.c:3179
>> 0xe64d8a find_bb_boundaries
>>        ../../src/gcc/cfgbuild.c:522
>> 0xe64d8a find_many_sub_basic_blocks(simple_bitmap_def*)
>>        ../../src/gcc/cfgbuild.c:604
>> 0x66e689 execute
>>        ../../src/gcc/cfgexpand.c:5905
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> Please include the complete backtrace with any bug report.
>> See <http://gcc.gnu.org/bugs.html> for instructions.
> 
> Well, look at the CFG and see if it makes sense and why it expects
> a single successor and why there is none.  Basically, work back
> from the ICE ...
> 
> Richard.
> 
>> Best regards,
>> Benedikt
>> 
>> On 27 May 2014, at 17:35, Benedikt Huber <benedikt.huber@theobroma-systems.com> wrote:
>> 
>>> 
>>> On 27 May 2014, at 17:25, Richard Biener <richard.guenther@gmail.com> wrote:
>>> 
>>>> On Tue, May 27, 2014 at 5:17 PM, Benedikt Huber
>>>> <benedikt.huber@theobroma-systems.com> wrote:
>>>>> 
>>>>> On 27 May 2014, at 17:09, Richard Biener <richard.guenther@gmail.com> wrote:
>>>>> 
>>>>>> On Tue, May 27, 2014 at 5:03 PM, Benedikt Huber
>>>>>> <benedikt.huber@theobroma-systems.com> wrote:
>>>>>>> (Sorry for the duplicate.)
>>>>>>> 
>>>>>>> I managed to pass the needed parameters to the generated function.
>>>>>>> However I cannot pin down the reason why the compilation fails.
>>>>>>> It seems that the cfg is somehow broken, but I cannot tell how.
>>>>>>> Do you have any debugging hints?
>>>>>>> 
>>>>>>> As far as I can tell, the cfg is changed during the generation of the preheader
>>>>>>> (I do this to find the entry block easily.)
>>>>>>> and in the function move_sese_region_to_fn.
>>>>>>> 
>>>>>>> I noticed that after pass 058t.copyrename2 the original function bar disappears
>>>>>>> and the new function is replaced by _GLOBAL__N_bar.constprop, could this have
>>>>>>> anything to do with the problem?
>>>>>> 
>>>>>> Unlikely.  You can disable that by using -fno-ipa-cp.
>>>>>> 
>>>>>>> The pass runs just after the construction of cfg,  outline.c.011t.cfg.
>>>>>>> 
>>>>>>> /home/bhuber/sandbox/install/bin/gcc -O3 -I /home/bhuber/sandbox/src -c -fdump-tree-all-details -fdump-ipa-all-details -fdump-rtl-all-details -funinline-innermost-loops -Wall -Wextra /home/bhuber/sandbox/try/outline.c
>>>>>>> /home/bhuber/sandbox/try/outline.c: In function '_GLOBAL__N_bar.constprop':
>>>>>>> /home/bhuber/sandbox/try/outline.c:3:1: internal compiler error: in purge_dead_edges, at cfgrtl.c:3183
>>>>>> 
>>>>>> the line doesn't match anything that would ICE on current trunk, but I suppose
>>>>>> it's the single_succ_p assert that triggers?
>>>>> Yes, that is right, it is
>>>>> 
>>>>> gcc_assert (single_succ_p (bb));
>>>>> 
>>>>>> 
>>>>>> Either you really got until RTL generation or somehow cfgrtl cfg hooks are
>>>>>> still active while you are working in your pass.
>>>>> 
>>>>> The pass that fails, according to the dump files is outline.c.174r.expand
>>>>> So it already tries to generate RTL.
>>>>> My problem is that there are so many passes in
>>>>> between, that I do not know where to start looking.
>>>>> Any idea?
>>>> 
>>>> What code-base are you developing on?  Do you build with checking
>>>> enabled (--enable-checking, the default on trunk but not on release branches).
>>> 
>>> It is a linaro branch, but I am going to port the pass to the fsf trunk and see
>>> whether the behaviour changes.
>>> 
>>> Best regards,
>>> Benedikt
>>> 
>>>> 
>>>> Richard.
>>>> 
>>>>>> 
>>>>>> Richard.
>>>>>> 
>>>>>>> bar (int s, int r, unsigned * t, int * k, int * p, int * l)
>>>>>>> ^
>>>>>>> 0x67e7c4 purge_dead_edges(basic_block_def*)
>>>>>>>    ../../src/gcc/cfgrtl.c:3183
>>>>>>> 0xe5a0d6 find_bb_boundaries
>>>>>>>    ../../src/gcc/cfgbuild.c:522
>>>>>>> 0xe5a0d6 find_many_sub_basic_blocks(simple_bitmap_def*)
>>>>>>>    ../../src/gcc/cfgbuild.c:604
>>>>>>> 0x66c0f5 execute
>>>>>>>    ../../src/gcc/cfgexpand.c:5873
>>>>>>> Please submit a full bug report,
>>>>>>> with preprocessed source if appropriate.
>>>>>>> Please include the complete backtrace with any bug report.
>>>>>>> See <http://gcc.gnu.org/bugs.html> for instructions.
>>>>>>> 
>>>>>>> I attach the transformation pass and the small example program.
>>>>>>> 
>>>>>>> Thank you again for the help,
>>>>>>> Benedikt
>>>>>>> 
>>>>>>> P.s. I am aware that this transformation is not safe in general,
>>>>>>> however in this case it should work.
>>> 
>>