I have noticed gcc has a preference for generating UXTB instructions when an AND with #255 would do the same thing. This is bad, because on A9 UXTB has two cycles latency compared to one cycle for AND. On A8 both instructions have one cycle latency.
On 03/08/12 13:49, Mans Rullgard wrote:
I have noticed gcc has a preference for generating UXTB instructions when an AND with #255 would do the same thing. This is bad, because on A9 UXTB has two cycles latency compared to one cycle for AND. On A8 both instructions have one cycle latency.
UXTB on the other hand is a 16-bit instruction, whereas AND is a 32-bit one.
Of the cores I'm aware of, only A9 has this performance anomaly.
R.
On 3 August 2012 13:53, Richard Earnshaw rearnsha@arm.com wrote:
On 03/08/12 13:49, Mans Rullgard wrote:
I have noticed gcc has a preference for generating UXTB instructions when an AND with #255 would do the same thing. This is bad, because on A9 UXTB has two cycles latency compared to one cycle for AND. On A8 both instructions have one cycle latency.
UXTB on the other hand is a 16-bit instruction, whereas AND is a 32-bit one.
Only in Thumb.
Of the cores I'm aware of, only A9 has this performance anomaly.
It is also a very widely used core.
On Fri, Aug 3, 2012 at 3:53 PM, Richard Earnshaw rearnsha@arm.com wrote:
On 03/08/12 13:49, Mans Rullgard wrote:
I have noticed gcc has a preference for generating UXTB instructions when an AND with #255 would do the same thing. This is bad, because on A9 UXTB has two cycles latency compared to one cycle for AND. On A8 both instructions have one cycle latency.
UXTB on the other hand is a 16-bit instruction, whereas AND is a 32-bit one.
Of the cores I'm aware of, only A9 has this performance anomaly.
While you are at it, please also consider blacklisting UXTAB instruction variants when tuning for Cortex-A9 unless optimizing for size. I was fairly confident that I had a feature request in gcc bugzilla about this, but apparently this is not the case. My bad.
On 4 August 2012 00:53, Richard Earnshaw rearnsha@arm.com wrote:
On 03/08/12 13:49, Mans Rullgard wrote:
I have noticed gcc has a preference for generating UXTB instructions when an AND with #255 would do the same thing. This is bad, because on A9 UXTB has two cycles latency compared to one cycle for AND. On A8 both instructions have one cycle latency.
UXTB on the other hand is a 16-bit instruction, whereas AND is a 32-bit one.
Of the cores I'm aware of, only A9 has this performance anomaly.
The CoreMark regression between 4.4 and 4.5 that Chung-Lin fixed was due to an AND being replaced with a UXTB. The instruction is slower, and the AND does a compare with zero for free.
-- Michael
linaro-toolchain@lists.linaro.org
-
Mans Rullgard -
Michael Hope -
Richard Earnshaw -
Siarhei Siamashka