Optimize load 0.0 for NEON seems not to work

Hi there. Could you tell me a bit more about the problem? What version of cairo? How is the rendering broken? How can I reproduce it?

I can't find a bug here, apart from perhaps that the test case (gcc/testsuite/gcc.target/arm/neon-load-df0.c) is not written very robustly. The compiler is making a sane choice when compiling that test: there's no particular need to use a NEON register for the operation in question, whether or not the hard-float ABI is in use. An alternative test case, e.g. simply:

double bar ()
{
  return 0.0;
}

compiled with -mfloat-abi=hard, reveals that the load-double-zero patch does work correctly (in a case where using a NEON register is definitely beneficial).

The Cairo problem must be something more subtle: we'd need a proper test case to figure that one out, as Michael hints at.

On Tue, Nov 9, 2010 at 11:08 AM, Julian Brown <email address hidden> wrote:
> I can't find a bug here, apart from perhaps that the test case
> (gcc/testsuite/gcc.target/arm/neon-load-df0.c) is not written very
> robustly. The compiler is making a sane choice when compiling that test:
> there's no particular need to use a NEON register for the operation in
> question, whether or not the hard-float ABI is in use. An alternative
> test case, e.g. simply:
>
> double bar ()
> {
>  return 0.0;
> }
>
> compiled with -mfloat-abi=hard, reveals that the load-double-zero patch
> does work correctly (in a case where using a NEON register is definitely
> beneficial).
>

how about -mfloat-abi=soft-fp ? thats where we see the problem.
It will take some time to pin down the problem in cairo. Let me try to
gather details
and see if we can have something put together.
> --
> Optimize load 0.0 for NEON seems not to work
> https://bugs.launchpad.net/bugs/667490
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I didn't mean to imply the test written in my previous comment was _broken_ with -mfloat-abi=softfp, but it does compile to (in Thumb mode):

        movs r0, #0
        movs r1, #0
        bx lr

which again is entirely sensible: for the soft-float ABI, the return value must be in core registers, so it'd be silly to load the 0.0 value into an FP register only to immediately transfer it to core registers.

Hi Khem. Any luck on reproducing the problem? Could you tell me what version of Cairo this is against, and if there's a test case that shows it?

*might* be related to https://bugs.launchpad.net/gcc-linaro/+bug/709453