https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122502
--- Comment #15 from Andrew Macleod <amacleod at redhat dot com> --- OK, more time for a decent comment.. > > That said, the "easiest" solution might be to do sth like > > auto_vec<gimple *> uses = get_imm_use_stmts (); > for (.. : uses) > fold_stmt (); > > it might look tempting to rewrite FOR_EACH_IMM_USE_STMT to always collect > a temporary vector of stmt uses first, similar as to how loop iterators > work. But that might be quite costly. we could make a version of that available... and only use it in cases that could be nested.. ie like from within ranger > > The checking code above could also detect when the immediate use list of > an SSA name that is iterated over is changed which might or might not be > "safe" (it might at least be unexpected). > That might be also useful...or at least some variant.. if any version of an immediate use traversal is underway, set a flag. Ranger won't return wrong results if it doesn't do the traversal, just possible it might miss an inferred range somewhere. > That said - does ranger really need to look at immediate uses from folding > context? This on-demand filling bites back here and makes things a lot more > fragile as to at which point we have to have an absolutely consistent IL. > Maybe have a ranger->stop_fill (), ranger->start_fill () flag passes could > set around code that does IL transforms but fold()s to avoid running into > these kind of issues? enable_range() by default assumes its going to be used in an on-demand nature, and so will only see statements that are directly involved in calculating the requested range. It follows the def chains and defs of uses in those def. In this mode, its really easy to miss things like a pointer deference which would provide a non-zero range. The first time an ssa_name is encountered by ranger in this mode, it quickly scans all the uses, and registes inferred ranges for any uses in their blocks. This allows the cache which does BB dom searches to then see these inferred ranges, and incorporate them, If ranger is enabled without immediate_uses, (which is what VRP does, so its well tested), it assumes it is being processed in dominator order, and thus will already have seen any inferred ranges which might have an effect. In on-demand mode, if we could detect that there is an immediate use taversal under way, it could just forego the search, and all that happens is you might possibly miss an inferred range that matters. you shouldn't have any other problem. The other option is to use ranger in non-on demand mode.. but fold can be called from a lot of places, so that doesn't seem like a good choice. Another option could be to add a "safe" mode.. ie, when getting into sketchy areas, like this, ie wrap the use wirh query_safe() query_normal() which turns off the ability to use immediate_uses while in safe code... or anything else we think is dicey hmm. maybe we add that to the FOR_EACH_IMM_USE loop. call something like query_safe() at the start of the traversal, and then query_normal () at the end. That would be fairly trivial I think.., little overhead, and wold cause ranger to not do a traversal if there is one under way. I dont think we really need to do it on a per-ssa basis either...
