Re: [gsoc2015] Is Gimple FE eligible for gsoc this year?
On 15/3/18 下午10:08, "Diego Novillo" wrote: >On Wed, Mar 18, 2015 at 2:54 AM, xue yinsong wrote: > >> Somehow this project is not in the gsoc ideas list, and it’s been one year >> since the last commit(According to >> https://gcc.gnu.org/svn/gcc/branches/gimple-front-end/ChangeLog). >> >> Could someone tell me if this project is still active and eligible for this >> year’s gsoc? > >I'm not sure. You'd have to find someone willing to mentor. There are >other cleanups necessary for this to be viable. Perhaps start with >those? > > >Diego. I’m glad to get started now. Could you please give me some specific directions to work on ? Yinsong.
Re: [gsoc2015] Is Gimple FE eligible for gsoc this year?
I add the following code in parser.c to replace htab:
…
struct gimple_symtab_hasher : ggc_cache_hasher
{
/* Return the hash value of the declaration name of a gimple_symtab_entry_def
object pointed by ENTRY. */
static hashval_t hash(struct gimple_symtab_entry_def *base){return
IDENTIFIER_HASH_VALUE(base->id);}
/* Returns non-zero if ENTRY1 and ENTRY2 point to gimple_symtab_entry_def
objects corresponding to the same declaration. */
static bool equal (const struct gimple_symtab_entry_def *base1, const struct
gimple_symtab_entry_def *base2){return base1->id == base2->id;}
static void
handle_cache_entry(struct gimple_symtab_entry_def *&m)
{
extern void gt_ggc_mx (struct gimple_symtab_entry_def *&);
if (m == HTAB_EMPTY_ENTRY || m == HTAB_DELETED_ENTRY)
return;
else if (ggc_marked_p (m->id))
gt_ggc_mx (m);
else
m = static_cast (HTAB_DELETED_ENTRY);
}
};
/* Gimple symbol table. */
static GTY((cache)) hash_table *gimple_symtab;
…
But I got undefined symbols when compiling it:
…
Undefined symbols for architecture x86_64:
"gt_ggc_mx(gimple_symtab_entry_def*&)", referenced from:
gt_clear_caches_gt_gimple_parser_h() in parser.o
"gt_pch_nx(gimple_symtab_entry_def*&)", referenced from:
gt_pch_nx_hash_table_gimple_symtab_hasher_(void*) in parser.o
"_c_global_trees", referenced from:
gimple_main() in parser.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[3]: *** [gimple1] Error 1
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2
Could someone tell me how to fix this?
—
Regards,
Yinsong
>
Re: Question about Gimple FE
On 15/3/30 下午5:40, "Richard Biener" wrote: >On Mon, Mar 30, 2015 at 11:36 AM, Richard Biener > wrote: >> On Fri, Mar 27, 2015 at 4:00 PM, xue yinsong wrote: >>> Thanks for your reply to my proposal. >>> AFAIS, most of the files generated by -fdump-tree-all are presented in >>> C-like form instead >>> of in lisp-like tuple form. >>> So it’s better to implement a front end for the C-like gimple >>> representations. >>> >>> I want to make sure if I get the idea right. >>> >>> Besides, I’m uncertain about the following questions: >>> 1.I suppose the syntax of the original gimple file generated by >>> -fdump-tree-gimple would cover >>> the syntax of those generated in later stages. Could some one tell me if >>> that’s correct? >> >> Well - in 004t.gimple there is still no CFG and we are not in SSA >> form, so syntax of 'gimple' >> would change slightly dependent on properties of the IL. GCC goes to >> various lowering stages >> (also for things like OpenMP, nested function and exception handling >> support). > >Btw, I wouldn't necessarily try to parse exactly those dump format - >streamlining it for >easier parsing would be ok, especially for the basic-block markers. >There was a request >multiple times to make it easier to adjust a function cut&pasted from >a dump produced >by -fdump-tree to valid C (thus accepted by gcc). One annoying >road-block is how we >dump labels and goto destinations. I tried to compile some simple programs with -fdump-treep-all and read some of the dumped files. I have the following comments. If I said something wrong please correct me. I suppose our goal is to translate the dumped program back to the C source code (otherwise we can simply retain the gotos and labels since they are already `valid’ in C). In this case we have to convert the gotos back to if-elses and whiles. As long as CFG informations are given, it’s possible to get rid of these gotos. Apart from this, Gimple and C also have some differences in PHI nodes and exception handling code. They also need to be converted back to corresponding C syntax. — Yinsong > >>> 2.On my computer, it seems both -fdump-tree-gimple and >>> -fdump-tree-gimple-raw dump the code to .004t.gimple. >>> tf -fdump-tree-all is used, only the result of -fdump-tree-gimple will be >>> presented. >>> Does gcc behave this way on purpose? >> >> I think so. -raw is a dump modifier while -all selects '-gimple' and >> all others. >> >> Richard. >> >>> >>> >>> >>> —— >>> Best regards, >>> Yinsong Xue >>>
FW: Question about Gimple FE
On 15/4/3 下午11:00, "xue yinsong" wrote: >So it’s better not to try to read the exact dump format. >Could we use a similar but more complete syntax instead? > >—— >Yinsong > >On 15/4/3 下午9:45, "Diego Novillo" wrote: > >> >> >>On 04/02/15 11:59, xue yinsong wrote: >>> I suppose our goal is to translate the dumped program back to >>> the C source code (otherwise we can simply retain the gotos and >>> labels since they are already `valid’ in C). In this case we have to >>> convert the gotos back to if-elses and whiles. As long as >>> CFG informations are given, it’s possible to get rid of these gotos. >> >>Not quite. The output of the debug dumpers is not really meant to be fed >>back to the compiler. They are debug dumps only. They do not contain >>enough information for code generation or analysis. >> >>Gimple needs a text form that can be manually or automatically >>generated. This form needs to represent the complete state of the IL >>needed to continue codegen/analysis/optimization. >> >>Ideally, one would be able to generate gimple at any arbitrary point in >>the compilation pipeline, and also inject gimple at any arbitrary point. >>This way, we can generate tests that exercise exactly one pass in the >>compiler (which means, it should be able to execute exactly one analysis >>or transformation pass, but that's another issue). >> >>Whether the debug dumpers end up using the gimple generation routines is >>another question. I think in the long term, it will make sense to have >>the debug dumpers generate output in the same syntax expected by the >>gimple parser, however. >> >> >>Diego.
