Re: Tr : "White paper" about GCC front-end internals

Re: Tr : "White paper" about GCC front-end internals

[Andi Hellmund]

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
>

Re : Tr : "White paper" about GCC front-end internals

[charfi asma]

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
>