[Bug middle-end/92957] gcc produces a duplicated load, clang doesn't

2019-12-18 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92957

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-18
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #3 from Andrew Pinski  ---
This is what I get on aarch64:
ldr x2, [x1]
str x2, [x0]
str xzr, [x1]
ldr x2, [x0]
sub x2, x2, #2
cmp x2, 1
bls .L6
ret
.p2align 2,,3
.L6:
ldr w1, [x1, 8]
str w1, [x0, 8]

Looks like GCC is losing restrict information somewhere.

What is more interesting is GCC does not combine:
  if (_5 <= 3)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870913]:
  MEM[(union any *)a_3(D)].st = _5;
  MEM[(union any &)b_2(D)].st = 0;
  goto ; [100.00%]

   [local count: 536870913]:
  _6 = (void *) _5;
  MEM[(struct exception_ptr *)a_3(D)]._M_exception_object = _6;
  MEM[(struct exception_ptr &)b_2(D)]._M_exception_object = 0B;


At the tree level.
This might be the reason why restrict is being lost.  It is combined at the RTL
and that might be the reason why it is lost.  BUT GImple level PRE should have
figured out the stores don't change the value.  So even that does not use
restrict here.  I have not debugged why though.  I even try adding restrict in
places but it does not change the results.

[Bug middle-end/92957] gcc produces a duplicated load, clang doesn't

2019-12-18 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92957

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #2 from Andrew Pinski  ---
NOTE testcase does not compile.  I needed to add:
#include 

To get it to compile.
Also note mentioned is you need to compile with -std=c++2a.

[Bug middle-end/92957] gcc produces a duplicated load, clang doesn't

2019-12-16 Thread rafael at espindo dot la
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92957

Rafael Avila de Espindola  changed:

   What|Removed |Added

Version|9.2.1   |10.0

--- Comment #1 from Rafael Avila de Espindola  ---
gcc trunk (r279443) still produces the same code.