Re: [PATCH 4/5] vect: Request no-wrap bounds from DR analysis.

"Robin Dapp" <[email protected]> Thu, 06 Aug 2026 16:07:31 +0200
Newsgroups gmane.comp.gcc.patches
Message-ID <[email protected]>
>> +/* Reset DR_INNERMOST, DR_NOWRAP_BOUND, and access functions of DR.  
>> */
>> +
>> +void
>> +vect_reset_dr (data_reference *dr)

>
> I think this belongs in tree-data-ref.cc, but I also wonder whether
> it should be done upon analysis therein already?

>> +       }
>> +
>> +      if (assum && integer_onep (assum))
>> +       continue;
>> +
>> +      if (!assum || integer_zerop (assum))
>> +       {
>> +         vect_reset_dr (dr);
>
> See above.  Btw, what happens after this?  We'll eventually get
> gather/scatter?

Yes, that reset is to get a more graceful degradation.  I added a 
comment and moved it to tree-data-ref.cc.  At the same time I tried 
defending why we still need a reset here but failed.  I was thinking of 
contradicting bound requirements originally but I can't seem to come up 
with a test.  With the assumption structure being count < bound it's 
difficult (impossible?) to construct such a case.

What I did get to is a test where a "stupid" bound like 1 spoils the 
whole assumption and don't vectorize despite having a valid assumption.
I'll retreat to the argument that a DR that wraps at "1" wouldn't have 
performed well with gather/scatter either and falling back to scalar is 
not too bad.  But of course we could do better there.

>
>> +
>> +         if (dump_enabled_p ())
>> +           dump_printf_loc (MSG_NOTE, vect_location,
>> +                            "data reference address wraps, discarding "
>> +                            "no-wrap assumption: %G", DR_STMT (dr));
>> +         continue;
>> +       }
>> +
>> +      /* Accumulate assumptions.  */
>> +      if (nowrap_assum && nowrap_assum != assum)
>> +       nowrap_assum = fold_build2 (TRUTH_AND_EXPR, boolean_type_node,
>> +                                   nowrap_assum, assum);
>> +      else
>> +       nowrap_assum = assum;
>
> I wonder how ugly "related" assumptions get for grouped accesses?

For example :)

adding no-wrap assumption: ((((unsigned int) ~s1_51(D) >= (unsigned int) 
n_57(D) && (unsigned int) ~s2_53(D) >= (unsigned int) n_57(D)) && 
(unsigned int) ~s2_53(D) >= (unsigned int)
n_57(D)) && (unsigned int) ~s2_53(D) >= (unsigned int) n_57(D)) && 
(unsigned int) ~s2_53(D) >= (unsigned int) n_57(D)

where we don't even eliminate identical terms...

Perhaps we can do better by doing
  IV < MIN (bound1, bound2, ...)
rather than
  IV < bound1 && IV < bound2 ...
Testing that.

>> +      /* We consider to vectorize this loop by versioning it under
>> +        some assumptions.  In order to do this, we need to clear
>> +        existing information computed by scev and niter analyzer.  */
>> +      scev_reset_htab ();
>> +      free_numbers_of_iterations_estimates (loop);
>> +      /* Also set flag for this loop so that following scev and niter
>> +        analysis are done under the assumptions.  */
>> +      loop_constraint_set (loop, LOOP_C_FINITE);
>
> So this is still needed?

Yes for now, but not conceptually.  I have a local patch getting rid of 
it but it's not battle hardened yet.

The rest of your remarks are incorporated and I'm currently re-testing 
the whole batch, hoping to send out the version tomorrow.

-- 
Regards
 Robin