Re: [IA-64 PATCH] PR rtl-opt/14261: ifcvt.c vs emit_move_insn.

[James E Wilson <wilson at specifix dot com>]

On Mon, 2006-02-27 at 21:58, Roger Sayle wrote:
> it, just in case I've missed anything.  This fixes the ICE, and
> it looks like there are no endian issues, but I'm not certain.

I think there is an endian issue, though it is more a bit-endian problem
than a byte-endian problem.  If I build an ia64-hpux cross compiler, and
apply your patch, then a mix4.r instruction gets converted to a mix4.l
instruction.

The problem here is that ia64-hpux is byte big endian, but little bit
endian.  store_bit_field assumes that its input bit positions are byte
endian relative, and converts them to bit endian relative for the
bit-field instruction.  So if you want to extract bit offsets from a
bit-field instruction and feed them back into store_bit_field, then you
need to convert the bit endian relative numbers back into byte endian
relative numbers.  This conversion happens only for targets where the
byte and bit endians differ, like ia64-hpux.

See the code in store_bit_field that depends on BITS_BIG_ENDIAN.

This conversion might be a bit tricky, as it depends on whether the
zero-extract has a register or a mem as an operand.  This conversion is
obviously easier if the bit-field offsets are constants.  If the
bit-field offsets are not constants, then you will have to emit some RTL
arithmetic insns to compute the offsets.  There are some examples in
combine.c.  At this point, we seem to have a mess again.

I think the recog pnum_clobbers_to_add solution may be easier.

I took the time to run it under the debugger this time, and I see that
the zero_extract is coming from noce_process_if_block.  This has code to
check for a reg destination, except it allows any destination when
no_new_pseudos is false, i.e. before reload.  Extra checks could be
added here to reject problematic destinations, such as a zero_extract
dest.  The downside to this approach though is that we will miss out on
a valid optimization here.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com