Re: [cft] subreg validation round 2

[Bob Wilson <bwilson@tensilica.com>]

Richard Henderson wrote:
> This passes on i686, alpha, ia64, powerpc linux, and sparc-solaris.
> Given Ulrich's previous testing, it *ought* to pass on s390.  Any
> other takers before I check it in and have to pick up pieces after
> the fact?

I just finished testing the previous version of the patch for Xtensa, and I 
didn't see any regressions.  I'll try this version, too.

But speaking of picking up pieces after the fact....

Your change to assign_parm_setup_block() on 2004-11-13 is causing/exposing a 
problem for Xtensa targets.  Specifically, this piece:

*************** assign_parm_setup_block (tree parm, stru
*** 2648,2654 ****
   	    {
   	      rtx tem, x;
   	      int by = (UNITS_PER_WORD - size) * BITS_PER_UNIT;
! 	      rtx reg = gen_rtx_REG (word_mode, REGNO (data->entry_parm));

   	      x = expand_shift (LSHIFT_EXPR, word_mode, reg,
   				build_int_cst (NULL_TREE, by),
--- 2663,2669 ----
   	    {
   	      rtx tem, x;
   	      int by = (UNITS_PER_WORD - size) * BITS_PER_UNIT;
! 	      rtx reg = gen_lowpart (word_mode, entry_parm);

   	      x = expand_shift (LSHIFT_EXPR, word_mode, reg,
   				build_int_cst (NULL_TREE, by),

The Xtensa FUNCTION_ARG macro is returning a BLKmode REG for a 3-byte struct 
argument.  This used to be converted to an SImode REG, but now it gets passed to 
gen_lowpart, which barfs on the BLKmode argument.

Is this my bug?  If so, should I change FUNCTION_ARG code to avoid returning a 
BLKmode reg?  Should I wrap the REG in a PARALLEL?  Something else?

My apologies if this has already been discussed -- I haven't kept up with recent 
changes very well.

Thanks,
--Bob