On 3/14/19 4:43 AM, Richard Biener wrote: > On Wed, 13 Mar 2019, Richard Biener wrote: > >> On Wed, 13 Mar 2019, Bin.Cheng wrote: >> >>> On Wed, Mar 13, 2019 at 3:58 AM Richard Biener <rguent...@suse.de> wrote: >>>> >>>> >>>> This makes an attempt at fixing the most annoying parts of the GIMPLE >>>> FE unit testing - the lack of proper CFG preservation and hoops you >>>> need to jump through to make the CFG and SSA builders happy. >>>> >>>> Due to this the __GIMPLE specifiers takes two new flags, "cfg" >>>> for GIMPLE-with-a-CFG and "ssa" for GIMPLE-with-a-CFG-and-SSA. >>>> When there is a CFG you need to start basic-block boundaries with >>>> >>>> __BB(index): >>>> >>>> where 'index' is the basic-block index. That implicitely defines >>>> a label __BBindex for use in goto stmts and friends (but doesn't >>>> actually add a GIMPLE_LABEL). >>>> >>>> The parsing code isn't defensive right now so you need to watch >>>> out to not use index 0 or 1 (entry and exit block) which are >>>> only implicitely present. >>>> >>>> As a proof of concept I added one BB annotation - loop_header(num) >>>> where "num" is the loop number. This means you can now also >>>> have loop structures preserved (to some extent - the loop tree is >>>> not explicitely represented nor are loop fathers, both are re-built >>>> via fixup). >>>> >>>> I've not yet adjusted -gimple dumping. >>>> >>>> I've adjusted all testcases I could find. >>>> >>>> The CFG build inside the frontend is a bit awkward (spread out...), >>>> likewise some functionality is asking for split-out. >>>> >>>> This is mainly a RFC for whether you think this is forward looking >>>> enough. Future enhancements would include EH and abnormal edges >>>> via stmt annotations: >>> Thanks very much for doing this. Do we have a centralized >>> wiki/document on the formal definition? It would be very helpful even >>> it's still evolving, otherwise we would need to dig into messages for >>> fragmented clues. >> >> Earlier this week I transformed the old >> https://gcc.gnu.org/wiki/GimpleFrontEnd page into one documenting >> the current state but this doesn't yet include any kind of documentation. >> >> I suppose special syntax documentation should go into our texinfo >> docs, I guess into a new section in the internals manual. Currently >> we only have documentation for the -fgimple switch. >> >> Note that I view -gimple dumping as the thing that should give you >> a clue about expected syntax. I hope to spend a little more time >> on the patch to make it ready for GCC9. > > I've settled on another change, forcing explicit gotos for fallthru > edges to the next block. > > Otherwise I've cleaned up the patch and removed no longer necessary > support for IFN_PHI from the middle-end. During cleanup I introduced > a gimple_parser class to hold the extra parsing state and I added > some extra error handling. > > Bootstrapped on x86_64-unknown-linux-gnu, testing is still in progress. > > I will commit this to make testcase extraction to GIMPLE more feasible > for GCC 9+ (we could even backport the GIMPLE FE changes to GCC 8 if > needed I guess). At least it will give me motivation to do further > required changes when I run into the next big LTO testcase running > into a loop optimizer issue... (non-loop passes should work fine > already). If it makes building testcases easier, then I'm all for it ;-)
jeff
