On 15/4/8 下午4:15, "Richard Biener" <richard.guent...@gmail.com> wrote:
>No. Currently we dump > > <bb 11>: > # i_57 = PHI <i_10(8)> > # ivtmp_60 = PHI <ivtmp_16(8)> > _65 = (int) ratio_mult_vf.8_45; > tmp.9_64 = i_30 + _65; > tmp.10_66 = ivtmp_33 - ratio_mult_vf.8_45; > if (niters.6_41 == ratio_mult_vf.8_45) > goto <bb 15>; > else > goto <bb 12>; > > <bb 12>: > # i_56 = PHI <tmp.9_64(11), i_30(6)> > # ivtmp_59 = PHI <tmp.10_66(11), ivtmp_33(6)> > goto <bb 9>; > >and <bb 11>: isn't a valid label in C. Dumping sth like _BB11: >instead would make it a valid label >and you need to do less editing to get it compile. > >Yes, PHIs are another story ;) > >Likewise names of temporary variables passes generate are not always >valid identifiers (containing '.'s). > >IMHO trying to get -fdump-tree-cfg (dump after CFG build) emit mostly >valid C would be nice (that is, >before you go into SSA form and need to deal with PHIs). > >For SSA form we'd need to find a nice syntax for PHI nodes. I doesn't >need to be the same as used >in debugging dumps. Easy enough to parse would be using a function >call, thus for bb12 above > >_BB12: > i_56 = __PHI (tmp$9_64, &_BB11, i_30, &_BB6); > ivtmp_59 = __PHI (tmp$10_66, &_BB11, ivtmp_33, &_BB6); > goto _BB9; > >possibly less conflicting would be to allow '11:' as label as >extension so we can use literal 11 for >the __PHI argument. > >The point of re-using (parts of) the C frontend is that you get types >and decls for free. The GIMPLE >part is really the easy part of writing a gimple FE ;) > >You need to shortcut most of the C FEs specialities such as type >promotion rules and stuff, of course. > >Richard. That’s pretty much what I thought :) A potential problem is, the dump format doesn’t contain enough Information (like user-defined types) to reconstruct the GIMPLE. I guess that’s why we’re considering LLVM’s IR. — Yinsong
