On 4 June 2015 at 01:35, Jim Wilson <jim.wil...@linaro.org> wrote:
> I noticed that poor code is emitted for a long double 0.0. This testcase
> long double sub (void) { return 0.0; }
> void sub2 (long double *ld) { *ld = 0.0; }
> currently generates
> sub:
> ldr q0, .LC0
> ret
> ...
> sub2:
> ldr q0, .LC1
> str q0, [x0]
> ret
> where LC0 and LC1 are 16-byte constant table long double zeros. With
> the attached patch, I get
> sub:
> movi v0.2d, #0
> ret
> ...
> sub2:
> stp xzr, xzr, [x0]
> ret
>
> The main problem is in aarch64_valid_floating_const, which rejects all
> constants for TFmode. There is a comment that says we should handle
> 0, but not until after the movtf pattern is improved. This
> improvement apparently happened two years ago with this patch
> 2013-05-09 Sofiane Naci <sofiane.n...@arm.com>
> * config/aarch64/aarch64.md: New movtf split.
> ...
> so this comment is no longer relevant, and we should handle 0 now.
> The patch deletes the out of date comment and moves the 0 check before
> the TFmode check so that TFmode 0 is accepted.
>
> There are a few other changes needed to make this work well. The
> movtf expander needs to avoid forcing 0 to a reg for a mem dest, just
> like the movti pattern already does. The Ump/?rY alternative needs to
> be split into two, as %H doesn't work for const_double 0, again this
> is like the movti pattern. The condition needs to allow 0 values in
> operand 1, as is done in the movti pattern.
>
> I noticed another related problem while making this change. The
> ldp/stp instructions in the movtf_aarch64 pattern have neon attribute
> types. However, these are integer instructions with matching 'r'
> constraints and hence should be using load2/store2 attribute types,
> just like in the movti pattern.
OK, Thank you /Marcus
