Re: [avr-gcc-list] Improving bit manipulations in avr-gcc 4.x

[Georg-Johann Lay]

> 5) The pattern themselves work fine. 
>    However, avr.c:adjust_insn_length() makes many assumptions on
>    patterns and how they look like or don't look like.
>    This is very hard to maintain for komplex patterns, and also it is
>    error prone. Therefore, I did not (yet) implement the new stuff
>    on the adjust_insn_length-level. Is there a more convenient, less
>    error prone and more readable way to state insn lengths? Like,
>    e.g. to assign negative insn length to indicate that an alternative's
>    length needs adjustment?

The new patch is against trunk, so it should be easier to use.

I fixed the insn length problem in avr.c:adjust_insn_length by the 
new insn attribute "adjust_len" which, on the one hand, can protect
insn lengths from being altered, and, on the other hand, enlightens 
the interdependence of insn patters with adjust_insn_length.

The attribute defaults to "yes", i.e. the new attribute does not affect
old insns.

Georg-Johann

____________________________________________________________________
Psssst! Schon vom neuen WEB.DE MultiMessenger gehört? 
Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123

bit1-trunk-142584.patch
Description: Text Data