[Bug middle-end/112653] We should optimize memmove to memcpy using alias oracle

2023-11-22 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112653

--- Comment #6 from Richard Biener  ---
(In reply to Jan Hubicka from comment #5)
> > but the issue is that test2 escapes which makes this conflict:
> 
> It is passed to memmove which is noescape and returned.  Why local PTA
> considers returned values to escape?

The pointed to memory escapes which means that stores to it are not dead.
Mind we do not have a separate points-to set for escaped via return
(some functions can also "return" like via EH or longjmp, and we can't
really know the latter w/o IPA analysis).  Pointers can also escape to
global memory.

Special-casing the regular return path is sth that's possible (also IPA
points-to doesn't compute a "local" escaped at all but preserves the
non-IPA solution for that), but in the end it didn't seem important
enough for me to try doing that ...

We have the function entry state which is NONLOAL, ESCAPED is what
determines "global memory" for all sorts of optimizations.  If we
split out RETURN_ESCAPED then that would be ESCAPED | RETURN_ESCAPED
and alias disambiguation could avoid RETURN_ESCAPED.

But ESCAPED handling is complicated already ...

[Bug middle-end/112653] We should optimize memmove to memcpy using alias oracle

2023-11-22 Thread hubicka at ucw dot cz via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112653

--- Comment #5 from Jan Hubicka  ---
> but the issue is that test2 escapes which makes this conflict:

It is passed to memmove which is noescape and returned.  Why local PTA
considers returned values to escape?

[Bug middle-end/112653] We should optimize memmove to memcpy using alias oracle

2023-11-22 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112653

--- Comment #4 from Richard Biener  ---
We do use the alias oracle in folding memmove:

  /* If the destination and source do not alias optimize into
 memcpy as well.  */
  if ((is_gimple_min_invariant (dest)
   || TREE_CODE (dest) == SSA_NAME)
  && (is_gimple_min_invariant (src)
  || TREE_CODE (src) == SSA_NAME))
{
  ao_ref destr, srcr;
  ao_ref_init_from_ptr_and_size (, dest, len);
  ao_ref_init_from_ptr_and_size (, src, len);
  if (!refs_may_alias_p_1 (, , false))
{
  tree fn;
  fn = builtin_decl_implicit (BUILT_IN_MEMCPY);
  if (!fn)
return false;

but the issue is that test2 escapes which makes this conflict:

  # PT = null { D.2775 } (escaped, escaped heap)
  # ALIGN = 8, MISALIGN = 0
  # USE = nonlocal escaped
  # CLB = nonlocal escaped
  test2_4 = __builtin_malloc (1000);
  # PT = nonlocal escaped null
  test.0_1 = test;
  __builtin_memmove (test2_4, test.0_1, 1000);

it works for

char *test, *test3;
void
copy_test ()
{
char *test2 = __builtin_malloc (1000);
__builtin_memmove (test2, test, 1000);
__builtin_memmove (test3, test2, 1000);
  __builtin_free (test2);
}

where both memmove calls become memcpy.  So this isn't asking for better
folding but for better pointer analysis I guess.

[Bug middle-end/112653] We should optimize memmove to memcpy using alias oracle

2023-11-21 Thread hubicka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112653

--- Comment #3 from Jan Hubicka  ---
PR82898 testcases seems to be about type based alias analysis. However PTA
should be useable here.

[Bug middle-end/112653] We should optimize memmove to memcpy using alias oracle

2023-11-21 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112653

--- Comment #2 from Sam James  ---
See PR82898 especially...

[Bug middle-end/112653] We should optimize memmove to memcpy using alias oracle

2023-11-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112653

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
   Last reconfirmed||2023-11-21
   Severity|normal  |enhancement
 Ever confirmed|0   |1
   Keywords||alias, missed-optimization
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed, I had thought that this was recorded before too ...