This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Committed] ifcvt.c solution to PR9814


On Sat, May 28, 2005 at 11:39:16PM -0600, Roger Sayle wrote:
> >   else if (OBJECT_P (y) || CONSTANT_P (y) || GET_CODE (y) == SUBREG)
> >     emit_move_insn (x, y)
> >   else
> >     {
> >       emit_insn (gen_rtx_SET (VOIDmode, x, y));
> >       ...
> >     }
> 
> There's just one aspect of your suggestion that I don't fully understand.
> As shown by PR rtl-optimization/20369, that even before my "suspicious"
> use of emit_move_insn in noce_emit_move_insn, it was possible that the
> insn returned by emit_move_insn wasn't recognizable.

If that's true with one of the rtx'es allowed into that section,
then it's a target bug in their move expanders.  Unfortunately
Joern doesn't give us enough information to figure that out.

> My confusion with the code fragment you proposed was that it looked
> like you imply that by checking "OBJECT_P (y) || CONSTANT_P (y) || ..."
> that we can now guarantee that the resulting insn must always be
> recognizable?

Those are the kinds of things that emit_move_insn handles.

> 	* ifcvt.c (noce_emit_move_insn): Construct a SET pattern directly
> 	if the RHS isn't suitable for calling emit_move_insn.

Ok.


r~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]