This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix another problem with RTX_UNCHANGING_P (take 2)
> store_constructor makes the whole constructor /u if there are read-only
> fields in it for clear_storage, so one alternative is not to do this as
> in the patch below. My 2003-12-03 patch made RTX_UNCHANGING_P not to be
> set if cleared != 1 (set exactly by this code). I believe this is the
> only way to match RTX_UNCHANGING_P description in tm.texi, because
> otherwise we end up with the same /u memory set multiple times (in both
> cases with /u flag, but still).
I agree. Setting /u on the whole constructor clearly breaks the semantics of
RTX_UNCHANGING_P since we know at this point that there is at least one
element in the constructor.
> Another alternative is to fix IA-32 backend (and likely others too).
> There are many places where i386.md has chunks like:
> (set (mem:BLK (match_dup 3))
> (const_int 0))
> The code would need changing, so that at least the RTX_UNCHANGING_P flag
> is propagated from ix86_expand_* memory argument(s) to the patterns.
> This matters for clrstr, movstr, cmpstr etc.
> I'm not posting a patch for this one right now, but it would certainly not
> be a very short patch.
And not appropriate for the 3.3 branch I think.
> 2003-12-15 Jakub Jelinek <jakub@redhat.com>
>
> * expr.c (store_constructor): Don't set RTX_UNCHANGING_P for
> clear_storage's argument.
Seems fine to me. We'll certainly loose in some cases, but I don't see how
to avoid that without resorting to clearing each field individually.
Thanks.
--
Eric Botcazou