Il 11/04/2013 15:23, Amir Gonnen ha scritto: > 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),
Please submit a patch that applies cleanly (the above has mangled whitespace) and mention whether you have bootstrapped/regression-tested it on a primary platform (e.g. x86_64-linux). Thanks, Paolo > 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 >>> >> >
