This is the mail archive of the
mailing list for the GCC project.
Re: How can I generate a new function at compile time?
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Benedikt Huber <benedikt dot huber at theobroma-systems dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Tue, 27 May 2014 17:25:52 +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>
On Tue, May 27, 2014 at 5:17 PM, Benedikt Huber
> On 27 May 2014, at 17:09, Richard Biener <firstname.lastname@example.org> wrote:
>> On Tue, May 27, 2014 at 5:03 PM, Benedikt Huber
>> <email@example.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).
>>> bar (int s, int r, unsigned * t, int * k, int * p, int * l)
>>> 0x67e7c4 purge_dead_edges(basic_block_def*)
>>> 0xe5a0d6 find_bb_boundaries
>>> 0xe5a0d6 find_many_sub_basic_blocks(simple_bitmap_def*)
>>> 0x66c0f5 execute
>>> 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,
>>> P.s. I am aware that this transformation is not safe in general,
>>> however in this case it should work.