On Jan 21, 2025, Richard Biener <richard.guent...@gmail.com> wrote: > you can use bit_field_size () and bit_field_offset () unconditionally,
Nice, thanks! > Now, we don't have the same handling on BIT_FIELD_REFs but it > seems it's enough to apply the check to those with a DECL as > object to operate on. I doubt that will be enough. I'm pretty sure the cases I saw in libgnat in which BIT_FIELD_REF changed could_trap status, compared with the preexisting convert-and-access-field it replaced, were not DECLs, but dereferences. But I'll check and report back. (I'll be AFK for most of the day, alas) > Note we assume that x.a[i] (variable index) may trap, handling other cases > where variable size/offset is involved in the same conservative manner looks > reasomable. *nod*. So arranging for BIT_FIELD_REFs to also trap would be ok, and it wouldn't prevent the optimization if the BIT_FIELD_REF will have the same trap status. >> Yeah. It works. But then I figured we could take a safe step further >> and ended up with what I posted. > What about that short-circuit argument? How do we end up combining > two refs that could trap and emit that to a block that's no longer guarded > by the original separate conditions? We don't do that, we emit it to the same block as the original reference. But if the could_trap status is different (say, because the original reference could trap while the replacement doesn't), other optimizers may move it to an unsafe spot. Now, it occurs to me that, if only one of the references could trap, and we merge them and insert the merged load next to the one that doesn't, we have an even more subtle variant of the error at hand. I'm not sure how to trigger it, because alignment and size seem to guarantee we won't combine accesses with different trapping properties (though one could presumably be marked as non-trapping if it is dominated by another access to the same word), but I should probably guard against this. Will do. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer More tolerance and less prejudice are key for inclusion and diversity Excluding neuro-others for not behaving ""normal"" is *not* inclusive
