This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/64410] gcc 25% slower than clang 3.5 for adding complex numbers


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

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

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #1)
> There are a number of things that make it complicated.
> 1) gcc doesn't like to vectorize when the number of iterations is not known
> at compile time.

Not an issue, we know it here (it's symbolic)

> 2) gcc doesn't vectorize anything already involving complex or vector
> operations.

Indeed - here the issue is that we have C++ 'complex' aggregate
load / store operations:

  _67 = MEM[(const struct complex &)_75];
  __r$_M_value = _67;
...
  _51 = REALPART_EXPR <__r$_M_value>;
  REALPART_EXPR <__r$_M_value> = _104;
...
  IMAGPART_EXPR <__r$_M_value> = _107;
  _108 = __r$_M_value;
  MEM[(struct cx_double *)_72] = _108;

which SRA for some reason didn't decompose as they are not aggregate
(well, they are COMPLEX_TYPE).  They are not in SSA form either because
they are partly written to.  In this case it would have been profitable
to SRA __r$_M_value.  Eventually this should have been complex lowerings
job (but it doesn't try to decompose complex assignments).

> 3) the ABI for complex uses 2 separate double instead of a vector of 2
> double.

I think that's unrelated.

> I believe there are dups at least for 2).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]