[Bug 727464] New: ORC does not preserve NEON/VFP registers according to ARM PCS

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Tue Apr 1 14:56:05 PDT 2014


https://bugzilla.gnome.org/show_bug.cgi?id=727464
  GStreamer | orc | unspecified

           Summary: ORC does not preserve NEON/VFP registers according to
                    ARM PCS
    Classification: Platform
           Product: GStreamer
           Version: unspecified
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: critical
          Priority: Normal
         Component: orc
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: nathan.west at okstate.edu
         QAContact: gstreamer-bugs at lists.freedesktop.org
                CC: ds at schleef.org
     GNOME version: ---


Symptoms:
I'm working (on ARM hard float) with several SIMD-optimized subroutines
including some written in ORC. Each gets passed through a QA check where one of
the values sitting in VFP registers is a tolerance to compare results as a
sanity check. This value seems to get over written in some cases where ORC is
one of the kernels that gets run.

This only happens when we run ORC generated code on ARM hard float platforms.

Problem:
ORC does not define a method to push (vpush) and pop (vpop) VFP and NEON
registers to the stack. The ARM PCS
(http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf)
section 5.1.2.1 states that registers s16-s31 should be preserved across
subroutines.

Related Code:
ORC code:
https://github.com/gnuradio/gnuradio/blob/master/volk/orc/volk_32fc_s32f_magnitude_16i_a_orc_impl.orc
ASM output: http://pastebin.com/ErSqsXYf

As you can see the ASM output by orcc uses registers d8-d10 (s16-s21) which
should be preserved by a vpush in the prologue and vpop in the epilogue. I
tested with orc 0.4.17 and 0.4.18.1 from git master (today).

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list