This is the mail archive of the gcc@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: Modifying ARM code generator for elimination of 8bit writes - need help


On Thu, 2006-07-20 at 12:04, Dave Korn wrote:
> On 20 July 2006 07:03, Wolfgang Mües wrote:
> 
> > Hello Rask,
> > 
> > On Wednesday 19 July 2006 13:24, Rask Ingemann Lambertsen wrote:
> >> I've spotted a function named emit_set_insn() in arm.c. It might be
> >> the problem, because it uses gen_rtx_SET() directly.
> > 
> > But it's not the only function which uses gen_rtx_SET. There are also
> > much places with
> > 
> >>     emit_constant_insn (cond,
> >> 	gen_rtx_SET (VOIDmode, target, source));
> > 
> > Isn't it better to replace gen_rtx_SET?
> > 
> 
>   Is there any generic advice available as to when and why one should use
> emit_insn (gen_rtx_SET (....)) as opposed to emit_move_insn (...)?

emit_move_insn will validate that the operands and try to make things
work if they don't satisfy the predicates for mov<mode>; ultimately it
will end up calling the gen_mov<mode> insn to do the right thing. 
emit_insn (gen_rtx_set... just takes the two operands and forms a set
insn, so the operands can be anything that's valid in a set, for
example:

	op0 = reg
	op1 = plus(reg, const_int)

you can only use emit_insn (gen_rtx_set(...)) when you know that the
result is a valid insn (for the current context).

R.


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