Re: PR target/46329: Reject Neon structure constants

[Richard Earnshaw <rearnsha@arm.com>]

On Mon, 2011-04-04 at 11:34 +0100, Richard Sandiford wrote:
> This patch fixed PR target/46329, which is a problem that occurs
> when trying to reload:
> 
>     (set (reg:OI foo) (const_int 0))
> 
> There is no move alternative for moving constants directly into large
> numbers of VFPs, and it probably isn't going to be sensible to do that
> for all constants, even if proper support for large-int constants is
> implemented in future.  It also isn't feasible to use the normal ARM
> constant pool, since the vldN and vstN instructions don't support the
> required addressing modes.
> 
> At the moment, reload instead tries to load the constant through GPRs,
> having been told to do so by coproc_secondary_reload_class.
> That doesn't work either because there aren't enough (consecutive)
> GPRs to go around.
> 
> Instead, this patch forces constants to the target-independent
> constant pool.  Even if we do optimise the handling for "easy"
> constants like 0 in future, I think we'd still need this code
> for the more complicated cases.
> 
> An alternative would have been to make preferred_reload_class
> return NO_REGS, but we should get better code by exposing the
> restriction earlier.
> 
> The patch applies on top of:
> 
>     http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00194.html
>     http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00195.html
> 
> Tested on arm-linux-gnueabi.  OK to install?
> 
> Richard
> 

I'm uncomfortable about this.  Generally the ARM port doesn't work well
with the target-independent constant pool and it's better to assert that
this is empty when it comes to final assembly generation.  Can you
clarify by way of example how this patch is working please (ie some
sample output).

R.