------- Comment #3 from davidxl at gcc dot gnu dot org 2010-04-22 17:04 -------
(In reply to comment #2)
> (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.
This code sequence looks like a good motivating factor for
scalarizing/expansion. In fact, small arrays should be treated the same way as
records if all accesses are through compile time constant indices. This is a
common scenario after full unrolling.
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.
If the temp aggregate is passed to call and the calling convention is not
exposed at the IL level, then it is not a good sra candidate as no copy (both
code and storage) elimination will be exposed. In this one, the temp aggregate
is used as the RHS of an assignment, thus it is a good candidate to expand. So
will be the reverse case:
aggregate1 = aggregate2;
..
... = aggregate1.e1;
... = aggregate1.e2;
David
> 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.
>
--
davidxl at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |xinliangli at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43846
