* Re : Tr : "White paper" about GCC front-end internals
2011-05-30 8:26 ` Tr : "White paper" about GCC front-end internals Andi Hellmund
@ 2011-06-14 17:19 ` charfi asma
0 siblings, 0 replies; 2+ messages in thread
From: charfi asma @ 2011-06-14 17:19 UTC (permalink / raw)
To: Andi Hellmund; +Cc: gcc-help
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@andihellmund.com>
À : charfi asma <charfiasma@yahoo.fr>
Cc : Philip Herron <redbrain@gcc.gnu.org>; gcc-help@gcc.gnu.org
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@yahoo.fr>
> À : Andi Hellmund<mail@andihellmund.com>
> Cc : gcc-help@gcc.gnu.org
> 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@andihellmund.com>
> À : gcc-help@gcc.gnu.org; gcc@gcc.gnu.org
> 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
>
^ permalink raw reply [flat|nested] 2+ messages in thread