Here it is (also copied back the comment from the original patch):
@@ -3207,9 +3207,14 @@
DF_REF_REG_USE, bb, insn_info, flags);
df_uses_record (collection_rec, &XEXP (dst, 2),
DF_REF_REG_USE, bb, insn_info, flags);
+
+ /* Handle the case of zero_extract(mem(...)) in the set dest.
+ This special case is allowed only if the mem is a single byte and
+ is useful to set a bitfield in memory. */
+
if (GET_CODE (XEXP (dst,0)) == MEM)
- df_uses_record (collection_rec, &XEXP (dst, 0),
- DF_REF_REG_USE, bb, insn_info,
+ df_uses_record (collection_rec, &XEXP (XEXP (dst, 0), 0),
+ DF_REF_REG_MEM_STORE, bb, insn_info,
flags);
else
df_uses_record (collection_rec, &XEXP (dst, 0),
Thanks,
Amir
On Thu, Apr 11, 2013 at 4:06 PM, Paolo Bonzini <bonz...@gnu.org> wrote:
> Il 11/04/2013 14:57, Amir Gonnen ha scritto:
>> Hi Paolo,
>>
>> About 3 years ago I've sent a patch which was submitted by Kenneth
>> Zadeck on revision 153924 (See
>> http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00232.html)
>>
>> Recently we tried to update our gcc port from gcc-4.4 to gcc-4.8 and
>> discovered that the same lines of code were changed, thus breaking our
>> private port. The offending change was submitted by you on revision
>> 163854 and I found no information about the reasons for it in the
>> mailing lists.
>>
>> I would appreciate if you could explain the rational for removing the
>> previous handling of zero_extract(mem(...)) in the set dest, and why
>> it was replaced by DF_REF_REG_USE while it looks to me as
>> DF_REF_REG_MEM_STORE.
>
> I think that was simply a cut-and-paste error. Feel free to submit a
> patch like this:
>
> {
> if (GET_CODE (XEXP (dst,0)) == MEM)
> df_uses_record (collection_rec, &XEXP (dst, 0),
> - DF_REF_REG_USE, bb, insn_info,
> + DF_REF_REG_MEM_STORE, bb, insn_info,
> flags);
> else
> df_uses_record (collection_rec, &XEXP (dst, 0),
>
> I will review it happily.
>
> Paolo
>
>> There is a more general question here:
>> I can, of course, change it locally and my port would work. But the
>> change is not specific to my port, it's just that no other port
>> currently has zero-extract with mem destination. But if there ever be
>> one, it would benefit from my change. (and of course I'll benefit from
>> it when I update gcc version again, or if our private port ever become
>> public).
>>
>> So the question is - should I bother send such patches if no other
>> port is currently affected by them? (when the changes are still
>> general in their nature)
>>
>> Thanks,
>>
>> Amir
>>
>
