https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #30 from Aldy Hernandez <aldyh at redhat dot com> --- On 5/26/21 3:23 PM, rguenther at suse dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 > > --- Comment #29 from rguenther at suse dot de <rguenther at suse dot de> --- > On Wed, 26 May 2021, amacleod at redhat dot com wrote: > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 >> >> --- Comment #28 from Andrew Macleod <amacleod at redhat dot com> --- >> (In reply to rguent...@suse.de from comment #27) >>> On Wed, 26 May 2021, aldyh at redhat dot com wrote: >>> >>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499 >>>> >>>> --- Comment #26 from Aldy Hernandez <aldyh at redhat dot com> --- >>>> On Wed, May 26, 2021 at 10:34 AM rguenther at suse dot de >>>> <gcc-bugzi...@gcc.gnu.org> wrote: >>>> >>>>> It's probably too strict for multiple_of_p which is fine with >>>>> overflows that preserve modulo behavior. >>>> >>>> Could you provide an example? >>> >>> Like with DECL_SIZE being D.1234 * 8 as unsigned multiplication >>> and the query whether it's a multiple of 8. Once you have no >>> range for 'D.1234' you will signal overflow (correctly) but >>> even then it's still a mutliple of 8. >> >> Determining whether an arbitrary expression is a multiple of some number is >> not >> really something we can figure out via ranges. Well, that's not quite true. >> If >> we fully fleshed out the operations you care about, things like multiply or >> shift you could get some results. presumably things like multiply by 2,4,8 >> and >> 16.. if we created correct multi-ranges for those, a cast of the high >> precision >> range back to the original precision would yield an identical non-varying >> range. and for non-multiples/unsupported values we'd get varying or something >> not the same as the original value?. This would only work if the original >> value doesn't come out varying. Although if its varying, maybe you dont >> care >> and a match is ok anyway? We could have may_overflow_p also return the >> higher precision range for inspection if its true... > > I guess optimally multiple_of_p would check for each individual > operation it looks at whether the op is transparent for the > modulo query and only if not checks whether there's possible overflow > (where ranges could help). My POC gimple_ranger_wider class can just be overloaded and in range_of_expr, you could just hijack the operations you care about (PLUS_EXPR, MULTIPLY_EXPR, etc) and treat them specially. Just a thought... Aldy
