This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: How can I generate a new function at compile time?
- From: Benedikt Huber <benedikt dot huber at theobroma-systems dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Tue, 3 Jun 2014 16:19:34 +0200
- Subject: Re: How can I generate a new function at compile time?
- Authentication-results: sourceware.org; auth=none
- References: <2C1DB30D-9984-48C5-A7DF-19FF419C6E0F at theobroma-systems dot com> <CAFiYyc21CDRRAn44fzKsfH=C+G5NB-_94X4CBjHZPf7Hsno1mg at mail dot gmail dot com> <DDB19999-77F0-4991-AA65-555111EC1531 at theobroma-systems dot com> <CAFiYyc2OTGAocOKUm1j4u9pyz-qs68R=FPYHAaKLCTHrcW+80Q at mail dot gmail dot com> <F6459A45-C179-4F0D-B1B6-075F331816A1 at theobroma-systems dot com> <CAFiYyc0pCYc0B0YBk6yCrqfsg1oyhw+jwxadtx0ES-FmgzFEKw at mail dot gmail dot com> <1252B71D-BF28-426D-9C54-9E2784FCBE1A at theobroma-systems dot com> <CAFiYyc2-2dRT6aexviPBkabHF+JCoQPHywGpTHwz2j8c8OUxpQ at mail dot gmail dot com> <5E13C382-FE91-4CD7-B5E3-1BD1C9538E83 at theobroma-systems dot com> <592C7B20-A972-4F90-87A8-43587908B9AB at theobroma-systems dot com> <CAFiYyc1r357QhfLqX=T4JqXn5SWHd4Bdj27PoSWOGuvSR2Ee=Q at mail dot gmail dot com> <2FFC851A-9005-4BAD-BC3A-4C652D821B56 at theobroma-systems dot com> <CAFiYyc3j530kVJ5FwBKG+MmZnLoPtUW-epgTi0n=KRbwkPidtw at mail dot gmail dot com> <9EF4CCBD-9DB0-4591-8A43-4DD499B8ED72 at theobroma-systems dot com> <CAFiYyc1_b5+szNKsjLpihzHmB2P2V-xaWn=XyS49s8nDDcdFsA at mail dot gmail dot com>
Ah, now I get it.
So the reason is that comdats is the last ipa pass that is run.
I continue to look for the problem in purge_dead_edges.
Thank you for the explanation.
Best regards,
Benedikt
On 03 Jun 2014, at 16:10, Richard Biener <richard.guenther@gmail.com> wrote:
> On Tue, Jun 3, 2014 at 3:59 PM, Benedikt Huber
> <benedikt.huber@theobroma-systems.com> wrote:
>>
>> According to the output the ICE is in the newly generated function (_GLOBAL__N_bar)
>> which is the one that remains.
>> Further more the compilation continues until the
>> expand pass (outline.c.180r.expand), where the error happens.
>> The original function (bar) is last seen in outline.c.056i.comdats.
>> I am a little confused by that, since comdats does not change anything.
>> But maybe there is no connection between the violated assertion and the vanishing function.
>
> Well, if it ICEs in _GLOBAL__N_bar then compilation stops - passes after IPA
> are executed for one function all to the end, so this just means the
> original bar
> wasn't processed yet.
>
> Richard.
>
>> On 03 Jun 2014, at 15:14, Richard Biener <richard.guenther@gmail.com> wrote:
>>
>>> On Tue, Jun 3, 2014 at 3:03 PM, Benedikt Huber
>>> <benedikt.huber@theobroma-systems.com> wrote:
>>>>
>>>> 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?
>>>
>>> It probably vanishes because this is the function you ICE for?
>>>
>>>> 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.
>>>>>>>
>>>>>>
>>>>
>>