Re: Fwd: Using movw/movt rather than minipools in ARM gcc

[Roland McGrath <mcgrathr at google dot com>]

On Mon, Apr 30, 2012 at 9:02 AM, Richard Earnshaw <rearnsha@arm.com> wrote:
> It very much depends on your processor.

I suppose we are probably concerned primarily with recentish OMAP and
Tegra2 sorts of processors, but we are looking for generic good performance
solutions for ARMv7-A class processors.

> MOVW/MOVT are inherently serial and are unlikely to issue in parallel on
> a multi-issue processor.
> LDR is likely to hit cache and thus with appropriate scheduling only
> take up one cycle. ?Furthermore, there is a chance of the constant being
> shared which can never happen with MOVW/MOVT.

Understood.

> You also need to consider how you'd handle literals larger than 32-bits.
> ?It starts to get quite expensive to synthesize 64-bit and larger
> values, especially if you have an FPU or NEON and want to set the value
> in a VFP register; but pushing the values out to non-literal pool memory
> is quite expensive.

Sure.  We'd intended to tackle that later (and do have the option of
allowing constant pools for values of no more than 12 contiguous bytes).
We're just starting with the straightforward cases of 32-bit constants,
and we had been going on the assumption that using movw/movt for all these
cases would be the ideal starting point.

> setting prefer_constant_pool to 0 in a particular processor's tuning
> configuration should change the balance -- see the code in arm.[ch].
> This is a source-code change -- it's not selectable from the command line.

The tuning we're using already has prefer_constant_pool==0 (-march=armv7-a).
That's why we were surprised to see the example David posted use constant
pools under -O2 but not under -O1.


Thanks,
Roland