Revital Eres revital.eres@linaro.org writes:

Another issue is related to the regression I saw with SMS in libav's dsputil-ssd_int8_vs_int16_c. Consulting with Ayal regarding this it seemed that the regression was due to dependence between accumulations that can be avoided, more specifically we had the following case in vector code:

vec1 = vec1 + ... ... vec1 = vec1+ ... ... vec1 = vec1+ ... ... vec1 = vec1+...

to resolve this, I implemented a hack similar to MVE optimiation in the loop-unroller as follows:

vec1 = vec1 + ... ... vec2 = vec2+ ... ... vec3 = vec3+ ... ... vec4 = vec4+...

While I agree that's a useful transformation, do you have a few more details about the SMS regression? I assume both the non-SMS and SMS loops use the:

vec1 = vec1 + ... ... vec1 = vec1+ ... ... vec1 = vec1+ ... ... vec1 = vec1+...

chain, so what makes the SMS version of it worse than the non-SMS version?

Richard

Revital Eres revital.eres@linaro.org writes:

...

chain, so what makes the SMS version of it worse than the non-SMS version?

I attached the SMS dump file. The problematic loop is the one with "SMS succeeded 36 2" (there are three loops in total in this file). Due to these accumulators min ii is 36 which seems to cause SMS to take wrong decisions.

SMS iis 36 36 72 (rec_mii, mii, maxii)

OK, so the minimum ii comes from each dependency in the chain of 4 accumulations having a latency of 9 cycles. But the A9 TRM says:

If a multiply-accumulate follows a multiply or another multiply-accumulate, and depends on the result of that first instruction, then if the dependency between both instructions are of the same type and size, the processor uses a special multiplier accumulator forwarding. This special forwarding means the multiply instructions can issue back-to-back because the result of the first instruction in cycle 5 is forwarded to the accumulator of the second instruction in cycle 4. If the size and type of the instructions do not match, then Dd or Qd is required in cycle 3. This applies to combinations of the multiply-accumulate instructions VMLA, VMLS, VQDMLA, and VQDMLS, and the multiply instructions VMUL andVQDMUL.

So I think the problem is that successive VMLAs don't in fact have a latency of 9. However, this doesn't seem to be modelled in the ARM backend, either through bypasses or in a sched-reorder hook. In contrast, the A8 pipeline description has:

;; A multiply with a single-register result or an MLA, followed by an ;; MLA with an accumulator dependency, has its result forwarded so two ;; such instructions can issue back-to-back. (define_bypass 1 "cortex_a8_mul,cortex_a8_mla,cortex_a8_smulwy" "cortex_a8_mla" "arm_mac_accumulator_is_mul_result")

I'm not sure from the A9 description whether "following" means "immediately following", or whether gaps between instructions are allowed (and, in the latter case, whether the gap can be filled with arbitrary instructions, or whether restrictions apply, such as "anything but another NEON multiplication"). Ramana, do you know?

Anyway, I think this explains why the non-SMS loop executes more quickly than GCC expects, and why the SMS loop is slower than it needs to be. It might be worth comparing the two loops with -mtune=cortex-a8.

Richard

On 15 November 2011 09:19, Richard Sandiford richard.sandiford@linaro.org wrote:

Revital Eres revital.eres@linaro.org writes:

...

...

chain, so what makes the SMS version of it worse than the non-SMS version?

I attached the SMS dump file. The problematic loop is the one with "SMS succeeded 36 2" (there are three loops in total in this file). Due to these accumulators min ii is 36 which seems to cause SMS to take wrong decisions.

SMS iis 36 36 72 (rec_mii, mii, maxii)

OK, so the minimum ii comes from each dependency in the chain of 4 accumulations having a latency of 9 cycles.  But the A9 TRM says:

If a multiply-accumulate follows a multiply or another    multiply-accumulate, and depends on the result of that first    instruction, then if the dependency between both instructions are of the    same type and size, the processor uses a special multiplier accumulator    forwarding. This special forwarding means the multiply instructions can    issue back-to-back because the result of the first instruction in cycle    5 is forwarded to the accumulator of the second instruction in cycle    4. If the size and type of the instructions do not match, then Dd or Qd    is required in cycle 3. This applies to combinations of the    multiply-accumulate instructions VMLA, VMLS, VQDMLA, and VQDMLS, and the    multiply instructions VMUL andVQDMUL.

So I think the problem is that successive VMLAs don't in fact have a latency of 9.  However, this doesn't seem to be modelled in the ARM backend, either through bypasses or in a sched-reorder hook. In contrast, the A8 pipeline description has:

This should be identical for both the A8 and A9 descriptions.

;; Instructions using this reservation read their (D|Q)n operands at N2, ;; their (D|Q)m operands at N1, their (D|Q)d operands at N3, and ;; produce a result at N6 on cycle 4. (define_insn_reservation "cortex_a8_neon_mla_qqq_32_qqd_32_scalar" 9 (and (eq_attr "tune" "cortexa8") (eq_attr "neon_type" "neon_mla_qqq_32_qqd_32_scalar")) "cortex_a8_neon_dp_4")

I thought I spotted the bypass for this but you are right, there is no bypass that handles this particular case.

;; A multiply with a single-register result or an MLA, followed by an ;; MLA with an accumulator dependency, has its result forwarded so two ;; such instructions can issue back-to-back. (define_bypass 1 "cortex_a8_mul,cortex_a8_mla,cortex_a8_smulwy"               "cortex_a8_mla"               "arm_mac_accumulator_is_mul_result")

But that is modelling only scalar bypasses for the A8 indicating a back to back issue of a multiply followed by an mla. The A9 descriptions should handle this with appropriate issue restrictions.

I'm not sure from the A9 description whether "following" means "immediately following", or whether gaps between instructions are allowed (and, in the latter case, whether the gap can be filled with arbitrary instructions, or whether restrictions apply, such as "anything but another NEON multiplication").  Ramana, do you know?

I don't know the answer to that specific question and will have to try a few experiments.

Anyway, I think this explains why the non-SMS loop executes more quickly than GCC expects, and why the SMS loop is slower than it needs to be.  It might be worth comparing the two loops with -mtune=cortex-a8.

Richard