[Bug rtl-optimization/67413] New: Complex NOP expanded to several operations

[Bug rtl-optimization/67413] New: Complex NOP expanded to several operations

[glisse at gcc dot gnu.org]

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

            Bug ID: 67413
           Summary: Complex NOP expanded to several operations
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

_Complex unsigned f(_Complex int i){return i;}

yields

        movl    %edi, %eax
        shrq    $32, %rdi
        salq    $32, %rdi
        orq     %rdi, %rax
        ret

I read somewhere that complex integers are a deprecated gcc extension, but gcc
only warns in pedantic mode, and it should not be too hard to improve the
generated code.

Note that tree optimizers currently also fail to optimize the corresponding
code:

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

(using & CST instead of >> and << does not help)

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

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-09-01
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
My idea was always that the bswap pass would handle this kind of stuff...

[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 <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
             Blocks|                            |101926

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Maybe for:
  _1 = REALPART_EXPR <i_5(D)>;
  _2 = (long long unsigned intD.23) _1;
  _3 = IMAGPART_EXPR <i_5(D)>;
  _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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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 :).