On Tue, 10 Jun 2025, Jakub Jelinek wrote: > On Mon, Jun 09, 2025 at 07:46:28PM +0200, Jakub Jelinek wrote: > > > So using, say, get_all_dominated_blocks (we free dominators, possibly > > > PHI expansion might insert on edges) to get a PRE ordered set of > > > > I think PHI expansion does insert on edges. > > As for whether to expand in some different order, right now the patch > just uses ranger on demand only in cases when we need to know, I think > that is something done in many passes even when they don't process basic > blocks in some particular order (and after all, if processing of each > stmt in the bbs doesn't necessarily lead to any ranger action, I'm not sure > why it would matter). > I can certainly try to expand in different order if it would be helpful. > But currently > /* Dominators are not kept up-to-date as we may create new basic-blocks. */ > free_dominance_info (CDI_DOMINATORS); > and > init_block = construct_init_block (); > certainly creates new bb (BB_RTL) as new successor of ENTRY and makes it > dominate the former ENTRY successor if any. Plus expand_gimple_basic_block > can create further bbs (again BB_RTL) or remove edges. Though probably > the newly created bbs will be given higher indexes and so saving the bb > numbers from before the free_dominance_info call and using it to order the > bbs might work.
I guess it will only help if we'd do all parts of expansion in order, and I'm not sure this will be an easy refactoring (I'm talking about PHI expansion, BB expansion, sub-bb creation, abnormal edge re-creation). The goal would be to have the GIMPLE CFG "upthread" unmodified at the point we might do range queries. That means we'd have to expand back-to-front (and watch out for backedges). With your experiment of computing ranges for everything we're good from the ICE point-of-view. I think there's nothing we can do to reassure us of correctness, so I'd take Andrews advice here (aka, go ahead). The only thing we can do in theory is instrument each SSA def like with _1 = ...; verify_range (_1, min, max, ...); // we're using int/frange_max? where I have no idea how "interesting" injecting loads of calls like this into the RTL expansion is going to be (it's sth I wanted to do on GIMPLE at some point). Now, we're also interested at ranges at the point of uses of _1, so the number of verifications would explode (at least we could compare to the range at _1s definition and elide if equal). Richard. > > Jakub > > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
