Removed text relocation code in OpenMax assembly files.

Removed text relocation code in OpenMax assembly files.
Chromium issue # 8061013

Tested with N-4. Related FFTs' SNR same as before.

R=rtoy@google.com

Committed: 4261

[Kevin, 2013-06-19 02:20:08]

Shashi, I can't commit to Chromium, so here's a CL in WebRTC.

Ray, can you commit the same changes to Chromium after this one? Thanks.

[shashishekhar, 2013-06-19 17:17:18]

On 2013/06/19 02:20:08, Kevin wrote:
> Shashi, I can't commit to Chromium, so here's a CL in WebRTC.
> 
> Ray, can you commit the same changes to Chromium after this one? Thanks.

Thanks, Kevin, I just verified that applying this patch will fix all the
remaining textrel sections for Android.

[ajm, 2013-06-20 00:50:39]

On 2013/06/19 02:20:08, Kevin wrote:
> Shashi, I can't commit to Chromium, so here's a CL in WebRTC.
> 
> Ray, can you commit the same changes to Chromium after this one? Thanks.

The changes don't need to be committed exactly; you would roll openmax_dl in
Chrome DEPS:
http://src.chromium.org/viewvc/chrome/trunk/src/DEPS

[shashishekhar, 2013-06-20 00:55:27]

On 2013/06/20 00:50:39, ajm wrote:
> On 2013/06/19 02:20:08, Kevin wrote:
> > Shashi, I can't commit to Chromium, so here's a CL in WebRTC.
> > 
> > Ray, can you commit the same changes to Chromium after this one? Thanks.
> 
> The changes don't need to be committed exactly; you would roll openmax_dl in
> Chrome DEPS:
> http://src.chromium.org/viewvc/chrome/trunk/src/DEPS

Yep, and as soon as this gets rolled in Chromium, I will land a CL which will
enable a compiler flag that will cause build to fail if there are textrel
sections in Android binary.

[rtoy, 2013-06-24 17:55:29]

Sorry for the late reply.  I was out of the office.

Just a few minor optimizations.  

When this lands, I can roll the DEPS change to get this into chromium.

https://webrtc-codereview.appspot.com/1687004/diff/5002/dl/sp/src/armSP_FFT_C...
File dl/sp/src/armSP_FFT_CToC_FC32_Radix8_fs_unsafe_s.S (right):

https://webrtc-codereview.appspot.com/1687004/diff/5002/dl/sp/src/armSP_FFT_C...
dl/sp/src/armSP_FFT_CToC_FC32_Radix8_fs_unsafe_s.S:185: ORR     t0, t0, setStep,
LSL #16
Sorry for the late reply.

I think this could have been done using 

movw t0, 0x04f3
movt t0, 0x3f35

https://webrtc-codereview.appspot.com/1687004/diff/5002/dl/sp/src/armSP_FFT_C...
File dl/sp/src/armSP_FFT_CToC_SC32_Radix8_fs_unsafe_s.S (right):

https://webrtc-codereview.appspot.com/1687004/diff/5002/dl/sp/src/armSP_FFT_C...
dl/sp/src/armSP_FFT_CToC_SC32_Radix8_fs_unsafe_s.S:198: ORR     t0, t0, setStep,
LSL #16
I think this could have been done using

movw t0, 0x799a
movt t0, 0x5a82

https://webrtc-codereview.appspot.com/1687004/diff/5002/dl/sp/src/omxSP_FFTFw...
File dl/sp/src/omxSP_FFTFwd_RToCCS_F32_Sfs_s.S (right):

https://webrtc-codereview.appspot.com/1687004/diff/5002/dl/sp/src/omxSP_FFTFw...
dl/sp/src/omxSP_FFTFwd_RToCCS_F32_Sfs_s.S:303: VMOV    half[0], t0
I think this could have been using

vmov half[0], #0.5

(Not sure about the #0.5, but there should be some encoding for that constant. 
See Table A7-18 and section A7.5.1 of the DDI0406C ARM arch ref manual.)

[Kevin, 2013-06-24 22:20:04]

https://webrtc-codereview.appspot.com/1687004/diff/5002/dl/sp/src/armSP_FFT_C...
File dl/sp/src/armSP_FFT_CToC_FC32_Radix8_fs_unsafe_s.S (right):

https://webrtc-codereview.appspot.com/1687004/diff/5002/dl/sp/src/armSP_FFT_C...
dl/sp/src/armSP_FFT_CToC_FC32_Radix8_fs_unsafe_s.S:185: ORR     t0, t0, setStep,
LSL #16
On 2013/06/24 17:55:29, rtoy wrote:
> Sorry for the late reply.
> 
> I think this could have been done using 
> 
> movw t0, 0x04f3
> movt t0, 0x3f35

Nice suggestion. Done.

https://webrtc-codereview.appspot.com/1687004/diff/5002/dl/sp/src/armSP_FFT_C...
File dl/sp/src/armSP_FFT_CToC_SC32_Radix8_fs_unsafe_s.S (right):

https://webrtc-codereview.appspot.com/1687004/diff/5002/dl/sp/src/armSP_FFT_C...
dl/sp/src/armSP_FFT_CToC_SC32_Radix8_fs_unsafe_s.S:198: ORR     t0, t0, setStep,
LSL #16
On 2013/06/24 17:55:29, rtoy wrote:
> I think this could have been done using
> 
> movw t0, 0x799a
> movt t0, 0x5a82

Done.

https://webrtc-codereview.appspot.com/1687004/diff/5002/dl/sp/src/armSP_FFT_C...
dl/sp/src/armSP_FFT_CToC_SC32_Radix8_fs_unsafe_s.S:198: ORR     t0, t0, setStep,
LSL #16
On 2013/06/24 17:55:29, rtoy wrote:
> I think this could have been done using
> 
> movw t0, 0x799a
> movt t0, 0x5a82

Done.

https://webrtc-codereview.appspot.com/1687004/diff/5002/dl/sp/src/omxSP_FFTFw...
File dl/sp/src/omxSP_FFTFwd_RToCCS_F32_Sfs_s.S (right):

https://webrtc-codereview.appspot.com/1687004/diff/5002/dl/sp/src/omxSP_FFTFw...
dl/sp/src/omxSP_FFTFwd_RToCCS_F32_Sfs_s.S:303: VMOV    half[0], t0
On 2013/06/24 17:55:29, rtoy wrote:
> I think this could have been using
> 
> vmov half[0], #0.5
> 
> (Not sure about the #0.5, but there should be some encoding for that constant.

> See Table A7-18 and section A7.5.1 of the DDI0406C ARM arch ref manual.)

"VMOV D0[0]" doesn't accept a constant, but "VMOV D0" can. Result is ready in 2
cycles for the former but 3 cycles for the latter.
Since half[1-3] is not used anywhere and there's enough cycle cushions for the
result, it's good to use VMOV D0, #constant.
Done.

[rtoy, 2013-06-24 22:34:40]

https://webrtc-codereview.appspot.com/1687004/diff/5002/dl/sp/src/omxSP_FFTFw...
File dl/sp/src/omxSP_FFTFwd_RToCCS_F32_Sfs_s.S (right):

https://webrtc-codereview.appspot.com/1687004/diff/5002/dl/sp/src/omxSP_FFTFw...
dl/sp/src/omxSP_FFTFwd_RToCCS_F32_Sfs_s.S:303: VMOV    half[0], t0
On 2013/06/24 22:20:04, Kevin wrote:
> On 2013/06/24 17:55:29, rtoy wrote:
> > I think this could have been using
> > 
> > vmov half[0], #0.5
> > 
> > (Not sure about the #0.5, but there should be some encoding for that
constant.
> 
> > See Table A7-18 and section A7.5.1 of the DDI0406C ARM arch ref manual.)
> 
> "VMOV D0[0]" doesn't accept a constant, but "VMOV D0" can. Result is ready in
2
> cycles for the former but 3 cycles for the latter.
> Since half[1-3] is not used anywhere and there's enough cycle cushions for the
> result, it's good to use VMOV D0, #constant.
> Done.

Does using "vmov half, #0.5" actually work?  Doesn't that load a
double-precision 0.5 into d0? But we really want d0[0] to be 0.5, a
single-precision value.

[Kevin, 2013-06-24 22:50:36]

https://webrtc-codereview.appspot.com/1687004/diff/5002/dl/sp/src/omxSP_FFTFw...
File dl/sp/src/omxSP_FFTFwd_RToCCS_F32_Sfs_s.S (right):

https://webrtc-codereview.appspot.com/1687004/diff/5002/dl/sp/src/omxSP_FFTFw...
dl/sp/src/omxSP_FFTFwd_RToCCS_F32_Sfs_s.S:303: VMOV    half[0], t0
On 2013/06/24 22:34:40, rtoy wrote:
> On 2013/06/24 22:20:04, Kevin wrote:
> > On 2013/06/24 17:55:29, rtoy wrote:
> > > I think this could have been using
> > > 
> > > vmov half[0], #0.5
> > > 
> > > (Not sure about the #0.5, but there should be some encoding for that
> constant.
> > 
> > > See Table A7-18 and section A7.5.1 of the DDI0406C ARM arch ref manual.)
> > 
> > "VMOV D0[0]" doesn't accept a constant, but "VMOV D0" can. Result is ready
in
> 2
> > cycles for the former but 3 cycles for the latter.
> > Since half[1-3] is not used anywhere and there's enough cycle cushions for
the
> > result, it's good to use VMOV D0, #constant.
> > Done.
> 
> Does using "vmov half, #0.5" actually work?  Doesn't that load a
> double-precision 0.5 into d0? But we really want d0[0] to be 0.5, a
> single-precision value.

Yes it works with a single precision value of 0x3f000000, from disassembly
output.

[rtoy, 2013-06-25 16:07:40]

lgtm