[Bug tree-optimization/67413] Complex NOP expanded to several operations

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> It would just work.

Except the two casts are not the same in the case of negative as I mentioned in
comment #2 :).

[Bug tree-optimization/67413] Complex NOP expanded to several operations

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Andrew Pinski  ---
As for the other testcase:
  y_3 = x_2(D) & -4294967296;
  z_4 = (intD.9) x_2(D);
  _1 = (long intD.12) z_4;
  _5 = _1 | y_3;

If we could optimize:
  z_4 = (intD.9) x_2(D);
  _1 = (long intD.12) z_4;

Into:
_1 = x_2(D) & 4294967295;

It would just work.

[Bug tree-optimization/67413] Complex NOP expanded to several operations

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Blocks||101926

--- Comment #3 from Andrew Pinski  ---
Maybe for:
  _1 = REALPART_EXPR ;
  _2 = (long long unsigned intD.23) _1;
  _3 = IMAGPART_EXPR ;
  _4 = (long long unsigned intD.23) _3;
  _6 = COMPLEX_EXPR <_2, _4>;

We should just create a VCE, I don't know if that is a good idea or not,
complex int in cases like this are not used that much anyways so 


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101926
[Bug 101926] [meta-bug] struct/complex argument passing and return should be
improved

[Bug tree-optimization/67413] Complex NOP expanded to several operations

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|rtl-optimization|tree-optimization

--- Comment #2 from Andrew Pinski  ---
At the tree level we get:
  _1 = REALPART_EXPR ;
  _2 = (unsigned int) _1;
  _3 = IMAGPART_EXPR ;
  _4 = (unsigned int) _3;
  _6 = COMPLEX_EXPR <_2, _4>;


But I suspect we could use VCE instead ...


> long f(long x){
>   long y = x >> 32;
>   y <<= 32;
>   int z = x;
>   return z | y;
> }

You have a sign extend in there.  That is the top bit of z (or the 32nd bit of
x) could done for the top 32bits of the return.  So this is not exactly the
same.
We do however optimize:
unsigned long f(unsigned long x){
  long y = x >> 32;
  y <<= 32;
  unsigned z = x;
  return z | y;
}

Now.