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).
