On Tue, Jan 21, 2025 at 10:52 AM Jakub Jelinek <ja...@redhat.com> wrote: > > On Tue, Jan 21, 2025 at 06:31:43AM -0300, Alexandre Oliva wrote: > > 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) > > I'd think if we know for sure access is out of bounds, we shouldn't be > creating BIT_FIELD_REF for it (so in case of combine punt on the > optimization). > A different thing is if we don't know it, where the base is say a MEM_REF > or something similar.
But we assume all indirect MEM_REFs may trap, likewise we check whether MEM_REFs of DECLs do out-of-bound accesses. The idea is to do the same for BIT_FIELD_REF when the access is based on a decl. I _think_ that should make them tree_could_trap_p at least. But sure, not creating BIT_FIELD_REFs that are "obviously" out-of-bound would be nice. That's why I suggested not creating them when the original ref was tree_could_trap_p - maybe only when the base get_inner_reference returned isn't a MEM_REF. Richard. > > Jakub >
