[Bug middle-end/97656] New: Specify that there is no address arithmetic on a pointer

[Bug middle-end/97656] New: Specify that there is no address arithmetic on a pointer

[tkoenig at gcc dot gnu.org]

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

            Bug ID: 97656
           Summary: Specify that there is no address arithmetic on a
                    pointer
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

This involves Fortran, but possibly also other languages.

Consider

$ cat alias.f90
program main
  interface
     subroutine foo(a)
       integer, intent(inout) :: a
     end subroutine foo
  end interface
  integer, dimension(2) :: x
  x(1) = 42
  x(2) = 42
  call foo(x(1))
  if (x(2) /= 42) stop "Error!"
end program main

This program specifies that foo has a scalar argument, passed by reference.
It is forbidden by Fortran's rules foo could access the element x(2),
therefore the call to stop could be optimized away, but it isn't:

$ gfortran -O3 -S alias.f90 
$ grep _gfortran_stop alias.s 
        call    _gfortran_stop_string
$ 

It would be good if there was a TREE_NO_POINTER_ARITHMETC (or simlar) flag
that could be set by the Fortran front end.

[Bug middle-end/97656] Specify that there is no address arithmetic on a pointer

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's of course not that simple since the GIMPLE IL can require pointer
arithmetic as implementation detail.  I guess we could try modeling this as 'fn
spec'
by making 'direct' even stricter meaning 'direct w/o additional offset' so
we can build an exact ao_ref here.  Maybe use

". WT"

for this?  And the discussed 'a'...'z' for the "upper case" '1'...'9', both
to denote the range is exact?  Note we discussed that we can this way
specify a must-def but here it's a may-def but with known offset.  Guess
must vs. may would rather be another first letter like 'D'? (and only 'direct'
supported there obviously)  And the upper case size specification means
at zero offset?

[Bug middle-end/97656] Specify that there is no address arithmetic on a pointer

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> Maybe use
> 
> ". WT"
> 
> for this?  And the discussed 'a'...'z' for the "upper case" '1'...'9', both
> to denote the range is exact?  Note we discussed that we can this way
> specify a must-def but here it's a may-def but with known offset.  Guess
> must vs. may would rather be another first letter like 'D'? (and only
> 'direct' supported there obviously)  And the upper case size specification
> means
> at zero offset?

Well, at least in the above case it is not just 0 offset, but any access from
the offset 0 (inclusive) to size of the type pointed by the argument
(exclusive).
E.g. if it is a structure, SRA must be surely be able to split it off and use
MEM_REFs even with non-zero offsets.

[Bug middle-end/97656] Specify that there is no address arithmetic on a pointer

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 2 Nov 2020, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97656
> 
> Jakub Jelinek <jakub at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |jakub at gcc dot gnu.org
> 
> --- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #1)
> > Maybe use
> > 
> > ". WT"
> > 
> > for this?  And the discussed 'a'...'z' for the "upper case" '1'...'9', both
> > to denote the range is exact?  Note we discussed that we can this way
> > specify a must-def but here it's a may-def but with known offset.  Guess
> > must vs. may would rather be another first letter like 'D'? (and only
> > 'direct' supported there obviously)  And the upper case size specification
> > means
> > at zero offset?
> 
> Well, at least in the above case it is not just 0 offset, but any access from
> the offset 0 (inclusive) to size of the type pointed by the argument
> (exclusive).
> E.g. if it is a structure, SRA must be surely be able to split it off and use
> MEM_REFs even with non-zero offsets.

Yes, we can only model the effect in the caller not constraints to the
actual IL in the callee.