On Mon, Oct 25, 2021 at 6:42 AM Jeff Law <jeffreya...@gmail.com> wrote:
>
>
>
> On 10/24/2021 8:15 PM, Jeff Law wrote:
> >
> >
> > On 10/18/2021 2:17 AM, Aldy Hernandez wrote:
> >>
> >>
> >> On 10/18/21 12:52 AM, Jeff Law wrote:
> >>>
> >>>
> >>> On 10/8/2021 9:12 AM, Aldy Hernandez via Gcc-patches wrote:
> >>>> The following patch converts the strlen pass from evrp to ranger,
> >>>> leaving DOM as the last remaining user.
> >>> So is there any reason why we can't convert DOM as well? DOM's use
> >>> of EVRP is pretty limited. You've mentioned FP bits before, but my
> >>> recollection is those are not part of the EVRP analysis DOM uses.
> >>> Hell, give me a little guidance and I'll do the work...
> >>
> >> Not only will I take you up on that offer, but I can provide 90% of
> >> the work. Here be dragons, though (well, for me, maybe not for you
> >> ;-)).
> > [ ... ]
> > So the failure I see it a bootstrap comparison failure affecting
> > omp-expand.c and cp/cp-gimplify.c. We end up generating different
> > code with and without debug symbols.
> Replying to myself....
>
>
> So we're getting different results from a call to fold_range_internal
> for this statement in bb #35 of expand_omp_target:
>
> (gdb) p debug_gimple_stmt (stmt)
> if (loop_171 != 0B)
>
>
> 259 res = fold_range_internal (r, s, NULL_TREE);
> (gdb) n
> 283 if (idx)
> (gdb) p res
> $60 = true
> (gdb) p r
> $61 = (irange &) @0x7fffffffdb20: {m_num_ranges = 1 '\001',
> m_max_ranges = 2 '\002', m_kind = VR_RANGE, m_base = 0x7fffffffdb30}
>
>
> vs
>
> 259 res = fold_range_internal (r, s, NULL_TREE);
> (gdb)
> 283 if (idx)
> (gdb) p res
> $16 = true
> (gdb) p r
> $17 = (irange &) @0x7fffffffdba0: {m_num_ranges = 1 '\001', m_max_ranges
> = 2 '\002', m_kind = VR_VARYING,
> m_base = 0x7fffffffdbb0}
>
> Anyway, not sure when I'll be able to look at this again, perhaps
> Wednesday. But my sense is something isn't right WRT the range of loop_171.
You can print the range in gdb by calling debug(r) or alternatively r->debug().
It'd be interesting to see why the statement got folded to two
different ranges. Did the IL change? Was a global range recorded in
SSA_NAME_RANGE_INFO that perhaps the ranger picked up? Actually, even
if the IL changed, it'd be interesting to see what exactly caused the
disparity.
Can you call gimple_ranger::dump_bb() on the problematic BB on both
compiles to see what the ranger sees for that BB?
You could also call debug_ranger() from within gdb and get a dump of
what a fresh ranger would be able to calculate with the current IL.
Try it on both compiles and send it to us, if you don't want to spam
the list.
Thanks.
Aldy
