Hello Andi, Thank you very much for your answer ;) However, I did already send the question to gcc mailing list: http://gcc.gnu.org/ml/gcc-help/2011-04/msg00402.html but I get no response that's why I re sent it to you :) I will try to change my front end in a way that it produce GIMPLE directly from my source language. hope it will be not very tricky !! Asma ----- Message d'origine ---- De : Andi Hellmund <mail@xxxxxxxxxxxxxxxx> À : charfi asma <charfiasma@xxxxxxxx> Cc : Philip Herron <redbrain@xxxxxxxxxxx>; gcc-help@xxxxxxxxxxx Envoyé le : Dim 29 mai 2011, 17h 09min 10s Objet : Re: Tr : "White paper" about GCC front-end internals Hey Asma, > I sent you this question last month but I do not get any response, could you > please help me finding answer to this question ? I'll try to, but I'm also CC'ing the gcc-help mailing list. Even though I sent around the whitepaper about GCC front-end internals, you shouldn't sent any questions regarding GCC front-ends only to me, but always to the gcc-help mailing list. The background is that I'm not working full-time on GCC (so I don't always have the time to answer promptly) and there are many people on the gcc-help mailing list who have more knowledge and experience than me about that. By sending your requests to the mailing list, you'll possibly get a faster answer than just writing to Phil and me :-) > You said in your paper that front end could not produce Generic at all > and target directly gimple. I would like to have some info about this idea. I was refering to that a front-end _could_ directly generate GIMPLE code, but it must not! But, I must admit that I've never done this so far, but I know that is is possible and that front-ends could do it. That's why I put it into the paper to mention alternatives. IMHO, the easiest approach is to generate GENERIC code (declarations and instructions) and let GCC transfer the GENERIC code to GIMPLE. This transformation from GENERIC to GIMPLE within GCC is done in function gimplify_function_tree. The resulting GIMPLE sequence is then stored in (struct function)->gimple_body via gimple_set_body(). Later in the compilation process, when the GENERIC/GIMPLE code is passed to the middle-end, e.g. cgraph_optimize_translation_unit as starting point, then the GCC code will check if the GIMPLE code is already available. That's only a schematic description, you should ideally look at a few examples in the source code. > Did those front ends use the gimplify function by passing a function that is > already in gimple form ? Unfortunately, I haven't seen that extensively. As an example, the C++ front-end is not purely based on GENERIC, but it extends GENERIC by some additional code which are then transformed by the front-end into GIMPLE in function cp_gimplify_expr. The front-end then uses the gimple-* functions to generate GIMPLE code. > i.e, In my front end I passed to gimplify a function that is a tree built in > GENERIC: > > gimplify_function_tree(main_fn_decl); > > could I simply pass instead main_fn_dec that is in gimple ? To my understanding, you always require the main_fn_decl (FUNCTION_DECL tree code) to be available. While the GENERIC code/instructions would be stored at DECL_SAVED_TREE, the GIMPLE code is stored in (struct function)->gimple_body. The (struct function) is stored in main_fn_decl via DECL_STRUCT_FUNCTION. I guess that you could build those structures up and then pass the main_fn_decl to the middle-end without using GENERIC instructions. I hope that helps you a little bit. If not, feel free to ask more specific questions on the mailing list. Best regards, Andi > ----- Message transféré ---- > De : charfi asma<charfiasma@xxxxxxxx> > À : Andi Hellmund<mail@xxxxxxxxxxxxxxxx> > Cc : gcc-help@xxxxxxxxxxx > Envoyé le : Mer 20 avril 2011, 10h 32min 39s > Objet : RE: "White paper" about GCC front-end internals > > > > > > ----- Message transféré ---- > De : Andi Hellmund<mail@xxxxxxxxxxxxxxxx> > À : gcc-help@xxxxxxxxxxx; gcc@xxxxxxxxxxx > Envoyé le : Dim 6 mars 2011, 22h 29min 55s > Objet : "White paper" about GCC front-end internals > > Hey ALL, > > after some time of source code investigations, testing and experiments, I > finally bundled my experiences with GCC front-ends in a "white paper" about the > internals of GCC front-ends. It is not really structured like a tutorial, but >it > > should hopefully be usuable by GCC newbies to speed up the introduction into > GCC. > > The white paper is available at: > > http://blog.lxgcc.net/wp-content/uploads/2011/03/GCC_frontend.pdf > > I'm pretty sure that this paper still contains some errors or even conceptual > mis-understandings, though I would appreciate to get feedback of any kind about > what could be improved/changed/removed. > > Once, all erros and mis-understandings are removed, I would then put some > important extracts of this paper into the GCC internals documentation to serve > as a base for future front-end documentations. > > Thanks for your feedback and time, > Andi > > Hello Andi, > > Congratulation for your paper, If it was written before I built version0.00001 > of my front end, it would have saved much time for me :) > > Any way, you said in your paper that front end could not produce Generic at all > and target directly gimple. I would like to have some info about this idea. > > Did those front ends use the gimplify function by passing a function that is > already in gimple form ? > > i.e, In my front end I passed to gimplify a function that is a tree built in > GENERIC: > > gimplify_function_tree(main_fn_decl); > > could I simply pass instead main_fn_dec that is in gimple ? > > thank you very much. > > Asma >
