On Tue, Aug 21, 2012 at 1:27 PM, Martin Jambor <mjam...@suse.cz> wrote: > On Wed, Aug 15, 2012 at 05:21:04PM +0200, Martin Jambor wrote: >> Hi, >> >> On Fri, Aug 10, 2012 at 04:57:41PM +0200, Eric Botcazou wrote: >> > > - ada/gcc-interface/utils.c:rest_of_subprog_body_compilation calls >> > > dump_function which in turns calls dump_function_to_file which calls >> > > push_cfun. But Ada front end has its idea of the >> > > current_function_decl and there is no cfun which is an inconsistency >> > > which makes push_cfun assert fail. I "solved" it by temporarily >> > > setting current_function_decl to NULL_TREE. It's just dumping and I >> > > thought that dump_function should be considered middle-end and thus >> > > middle-end invariants should apply. >> > >> > If you think that calling dump_function from >> > rest_of_subprog_body_compilation >> > is a layering violation, I don't have a problem with replacing it with a >> > more >> > "manual" scheme like the one in c-family/c-gimplify.c:c_genericize, >> > provided >> > that this yields roughly the same output. >> >> Richi suggested on IRC that I remove the push/pop_cfun calls from >> dump_function_to_file. The only problem seems to be >> dump_histograms_for_stmt > > Yesterday I actually tried and it is not the only problem. Another > one is dump_function_to_file->dump_bb->maybe_hot_bb_p which uses cfun > to read profile_status. There may be others, this one just blew up > first when I set cfun to NULL. And in future someone is quite likely > to need cfun to dump something new too. > > At the same time, re-implementing dumping > c-family/c-gimplify.c:c_genericize when dump_function suffices seems > ugly to me. > > So I am going to declare dump_function a front-end interface and use > set_cfun in my original patch in dump_function_to_file like we do in > other such functions. > > I hope that will be OK. Thanks,
Setting cfun has side-effects of switching target stuff which might have code-generation side-effects because of implementation issues we have with target/optimize attributes. So I don't think cfun should be changed just for dumping. Can you instead just set current_function_decl and access struct function via DECL_STRUCT_FUNCTION in the dumpers then? After all, it it is a front-end interface, the frontend way of saying "this is the current function" is to set current_function_decl, not the middle-end cfun. Richard. > Martin > > PS: Each of various alternatives proposed in this thread had someone > who opposed it. If there is a consensus that some of them should be > implemented anyway (like global value profiling hash), I am willing to > do that, I just do not want to end up bickering about the result.
