On Wed, May 24, 2017 at 6:04 PM, Richard Biener <richard.guent...@gmail.com> wrote: > On May 24, 2017 5:38:53 PM GMT+02:00, Andrew MacLeod <amacl...@redhat.com> > wrote: >>On 05/24/2017 04:25 AM, Richard Biener wrote: >>> > What's this overflow flag for anyway? >> >>The new on-demand range calculators do operations on ranges, and that >>flag is set when a range calculation may have overflowed... which is of >> >>use when issuing warnings or deciding to not use a range. >>ie given a made up example: >> >>signed char a,b; >>a_1 = b_3 +10; >>if (b_3 > 100) foo (a_1) >> >>on the true side we know b_3 has the range [101,127]. It also >>calculates the range of a_1 as [111, 127][-128,-119] and sets the >>overflow bit since the calculation of a_1 can overflow for some >>elements >>of the range of b_3. Anyone wanting to use the range can check the >>overflow if its something they care about. The overflow stuff has not >>been completely flushed out yet, but it is in place for the moment. we >> >>can decide down the road if it serves enough purpose to stick around, >>or >>needs expansion, or whatever. >>> > > That said, I think it's the wrong approach to start mucking with >>SSA > name associated ranges given they are supposed to be a cheap >>storage > variant of what VRP computes. Start by making the VRP >>machinery work > from on-demand-ranges. I do have some prototypes from >> >>last year or > the year before to do this -- the helpers VRP machinery >>is already > generic enough if you make use of VRPs range type. >> >>well its also no longer just contained to VRP. This work is all driven >>by the desire of other optimizations to access range information. Some >> >>have hacked their required bits into vrp, making vrp a sort of mini >>optimization phase, others have attempted to leverage assert_exprs at >>their point in time (not too successfully I think?) , others just live >>with the lack of contextual range info after VRP... after looking at >>it, >>i decided trying to teach other optimizations about assert_expr in >>order >>to make their info available later was not something that seemed like a >> >>good long term solution. >> >>The most pressing matter was the desire for CFG sensitive range >>information outside of VRP. Since assert_exprs are gone after VRP, we >>loose the information on the branches of a diamond without a lot of >>hackery. > > That's what my prototype does. I'll dig it out and will send it after public > holidays tomorrow. I do not believe in duplicating all the range operations > we have in VRP.
Ok, so finally found that prototype to expose such API, see attached. It of course no longer applies but its goal should be clear -- compute a value range of a GENERIC expr (might be just an SSA name) in given context (the prototype uses a loop *, but a BB would work here as well). It doesn't yet walk GIMPLE defs but only uses pre-recorded SSA values, it has an "interesting" way to gather dominating conditions and it lacks any caching. IMHO any such interface should work like SCEV operates, thus maintain a cache plus limiting stmt walks up to some dominator. VRP now has a (nicely) factored way to generate "asserts" for conditionals so you can register ranges for dominating asserts easily (and cache those). Rather than recursing like in the prototype you'd (at least for the non-GENERIC expr parts) compute a worklist of DEFs plus dominating conditions that are interesting and then do regular forward iteration. IMHO for any on-demant interface it's important that setup cost and cost is bound by the size of the "expression" involved. Richard.
fix-pr62630-2
Description: Binary data