------- Comment #2 from jamborm at gcc dot gnu dot org 2010-04-22 12:35 -------
(In reply to comment #1)
>
> so it doesn't consider the struct with the array for total scalarization
> for some reason. Martin?
>
Well, that was a deliberate decision when fixing PR 42585 (see
type_consists_of_records_p). The code is simpler because it does not
have to know how to iterate over the array index domain.
Of course, we can alleviate this restriction and learn how to iterate.
However, all the accesses for the whole array are already created,
that is not the issue. The problem basically is that when we see the
sequence
D.2035.m[0] = D.2044_20;
D.2035.m[1] = D.2043_19;
D.2035.m[2] = D.2042_18;
*b_1(D) = D.2035;
(and there are no other accesses to D.2035) the condition that tries
to prevent us from creating unnecessary replacements kicks in and we
decide not to scalarize. The intent of the current code (possibly
among other reasons) was to avoid going through a replacement when the
whole structure was then passed as an argument to a function and
similar situations. But it should not be very difficult to change the
condition (in analyze_access_subtree) to handle both situations right.
Doing this, rather than total scalarization for arrays (which should
be only useful as a substitute for a copy propagation) should enable
us to handle even huge arrays.
I'll get to this right after dealing with PR 43835.
--
jamborm at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2010-04-22 09:07:40 |2010-04-22 12:35:41
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43846
