Re: Modifying ARM code generator for elimination of 8bit writes - need help

[Wolfgang Mües <wolfgang at iksw-muees dot de>]

Rask,

On Tuesday 06 June 2006 21:33, Rask Ingemann Lambertsen wrote:
> > > +   swp%?b\\t%1, %1, %0\;ldr%?b\\t%1, %0"
> >
> > You should get a price for cleverness here!
>
> Thanks! Indeed it looks good until you think of volatile variables.

Because volatile variables can change their values from another thread, 
and the readback will be false. Oh.

gcc knows the volatile attribute here, I assume?

> > As far as I can tell now, this works good. But I think there are
> > many cases in which the source operand is not needed after the
> > store. Is there a possibility to clobber the source operand and not
> > using another register?
>
> I don't know if (match_scratch ...) might reuse the source operand.
> It can be attempted more specifically with an additional peephole
> definition:
>
> (define_peephole2
>   [(set (match_operand:QI 0 "memory_operand" "")
>         (match_operand:QI 1 "register_operand" ""))]
>   "TARGET_ARM && TARGET_SWP_BYTE_WRITES && peep2_reg_dead_p (1,
> operands[1])" [(parallel
>     [(set (match_dup 0) (match_dup 1))
>      (clobber (match_dup 1))]
>   )]
> )

I will try this.

> Yet another register which stands a good chance of being reusable is
> the register containing the address.

Yes, but that is not allowed according to the specification of the swp 
instruction. The address register must be different from the other 2 
registers. Is there any chance of gcc violating this constraint? 

regards
Wolfgang
-- 
We're back to the times when men were men 
and wrote their own device drivers.

(Linus Torvalds)