[Bug rtl-optimization/110237] gcc.dg/torture/pr58955-2.c is miscompiled by RTL scheduling after reload

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237

--- Comment #19 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 26 Jun 2023, amonakov at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
> 
> --- Comment #18 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
> (In reply to rguenther@suse.de from comment #17)
> > Yes, we do the same to loads.  I hope that's not a common technique
> > though but I have to admit the vectorizer itself assesses whether it's
> > safe to access "gaps" by looking at alignment so its code generation
> > is prone to this same "mistake".
> > 
> > Now, is "alignment to 16 is ensured externally" good enough here?
> > If we consider
> > 
> > static int a[2];
> > 
> > and code doing
> > 
> >  if (is_aligned (a))
> >    {
> >      __v4si v = (__attribute__((may_alias)) __v4si *) &a;
> >    }
> > 
> > then we cannot even use a DECL_ALIGN that's insufficient for decls
> > that bind locally.
> 
> I agree. I went with the 'extern' example because there it should be more
> obvious the construction ought to work.
> 
> 
> > Note we have similar arguments with aggregate type sizes (and TBAA)
> > where when we infer a dynamic type from one access we check if
> > the other access would fit.  Wouldn't the above then extend to that
> > as well given we could also do aggregate copies of "padding" and
> > ignore the bits if we'd have ensured the larger access wouldn't trap?
> 
> I think a read via a may_alias type just tells you that N bytes are accessible
> for reading, not necessarily for writing. So I don't see a problem, but maybe I
> didn't quite catch what you are saying.

I wasn't sure how to phrase, what I was saying is we have this
"the access is too large for the object in consideration, so it cannot
alias it" in places where we just work with types within the TBAA
framework.  So I wondered if one can construct a similar case to
support that we should not do this.  (tree-ssa-alias.cc:
aliasing_component_refs_p)

> 
> > So supporting the above might be a bit of a stretch (though I think
> > we have to fix the vectorizer here).
> 
> What would the solution be? Using a may_alias type for such accesses?

But the size argument doesn't have anything to do with TBAA (and
may_alias is about TBAA).  I don't think we have any way to circumvent
C object access rules.  That is, for example, with -fno-strict-aliasing
the following isn't going to work.

int a;
int b;

int main()
{
  a = 1;
  b = 2;
  if (&a + 1 == &b) // equality compare of unrelated pointers OK
    {
      long x = *(long *)&a; // access outside of 'a' not OK
      if (x != 0x0000000100000002)
        abort ();
    }
}

there's no command-line flag or attribute to form a pointer
to an object composing 'a' and 'b' besides changing how the
storage is declared.

I don't think we should make an exception for "padding" after
an object and I don't see any sensible way how to constrain
the size of the supported "padding" either?  Pad to the
largest possible alignment of the object?  That would be
MAX_OFILE_ALIGNMENT ...

> 
> > > > If the v4si store is masked we cannot do this anymore, but the IL
> > > > we seed the alias oracle with doesn't know the store is partial.
> > > > The only way to "fix" it is to take away all of the information from it.
> > > 
> > > But that won't fix the trapping issue? I think we need a distinct RTX for
> > > memory accesses where hardware does fault suppression for masked-out elements.
> > 
> > Yes, it doesn't fix that part.  The idea of using BLKmode instead of
> > a vector mode for the MEMs would, I guess, together with specifying
> > MEM_SIZE as not known.
> 
> Unfortunate if that works for the trapping side, but not for the 
> aliasing side.

It should work for both I think, but MEM_EXPR would need changing
as well - we do have a perfectly working representation there, it
would just be the first CALL_EXPR in such context ...