Re: extv, extzv and insv patterns

[Roman Lechtchinsky <rl at cs dot tu-berlin dot de>]

On Tue, 17 Jul 2001, David Edelsohn wrote:

> Roman> Which mode is operand 3 (the starting bit) supposed to be relative to
> Roman> (which is important if BITS_BIG_ENDIAN is 1)? Is it the mode of operand 1
> Roman> or word_mode? The code which calls these patterns seems to generally (but
> Roman> not always :-) assume the latter.
> 
> 	Operands 2 and 3 only are generated as constants, so the mode is
> not extremely important.  Note that extzv does not have a mode in the
> name, so there is only one pattern for a processor which supports multiple
> bit-sizes.  The tradition is to use the word size for the smallest
> bit-size of the processor (e.g., SImode for 32/64 processor).

Note that I didn't ask about the mode of operands 2 and 3 but the mode the
number of the starting bit is relative to. For instance, with
BITS_BIG_ENDIAN set to 0 and BYTES_BIG_ENDIAN set to 1 I currently get -8
as the bit number when extracting a 16-bit field. This is obviously
incorrect. The problem is that operand 1 has QImode and the code which
calls extzv tries to account for BITS_BIG_ENDIAN and BYTES_BIG_ENDIAN
being different by computing (roughly) x - bitsize - bitpos where x is the
mode size, bitsize is the size of the field and bitpos is the previously
computed bit position. This doesn't work since x is 8 in this case (the
size of QImode). I'd like to know what x is supposed to be.

> 	In general you should look at other ports to answer some of these
> questions.  Once you figure out the answers, we would be happy to accept
> patches to the GCC documentation to clarify these issues.

Yes, but I don't think I can figure this out by looking at existing ports
since gcc seems to exhibit incorrect behaviour in this case. I'd like to
fix this but I don't know how because I don't understand what the
behaviour *should* be.

Bye

Roman