Hello Alex,
On 18.07.2012 18:40, Alex Turjan wrote:
Im writing to you with respect to some strange SMS functionality.
In the code bellow there are 2 instructions (a builtin store and a builtin load)
as they appear in the program flow before SMS:
...
Issues:
1. What is the reason why (T,1) is build up? – to me it seams that (T,0)
must be enough
This looks like the issue that Roman's patch from
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01804.html should be fixing,
could you try it?
Ayal, Revital, could you again take a look at the above patch and all the
SMS improvement patches mentioned in
http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01859.html? The last comments
from me are at http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00478.html. At
the Cauldron, I was talking to Ramana about pushing these forward as
important for arm and Linaro, so it would be good to have them in 4.8.
Andrey
2. Looking inside generate_reg_moves it seams to me that this function
is not meant to deal with replacing memory accesses but only with
register replacements. (see inside the call to replace_rtx which in
my case trys to replace the mem accesses inside 136).
3. The (T,1) dep is assumed to take place as if before the SMS pass,
insn 136 was preceding insn 134:
(insn 136 135 137 12 tdscdma_pfu_ccdec.c:292
(set (reg/v:HI 248 [ mappingAddress_i16 ])
(unspec:HI [
(mem:HI (plus:PSI (reg/v/f:PSI 170 [ curMappingTable_pi16 ])
(reg:SI 305)) [0 S2 A16])
] 696)) 755 {INSN_BUILTIN___loadbyteofs_16} (expr_list:REG_DEAD
(reg:SI 305)
(nil)))
(insn 134 133 135 12 tdscdma_pfu_ccdec.c:289
(set (mem:HI (plus:PSI (reg/v/f:PSI 185 [ ccdecInterim_pi16 ])
(reg:SI 303)) [0 S2 A16])
(unspec:HI [
(reg/v:HI 244 [ outData_u16 ])
] 1752)) 1377 {INSN_BUILTIN___storebyteofs_16} (expr_list:REG_DEAD
(reg:SI 303)
(expr_list:REG_DEAD (reg/v:HI 244 [ outData_u16 ])
(nil))))
If that would be the case then between 134 and 136 there would be present
also an antidependence of distance 0. Becasue in the pipelined schedule,
134 is scheduled before 136 (SCHED_TIME (136) > SCHED_TIME (134)) the modulo
variable expansion needs to take place as explained before.
SMS decides to produce a modulo variable expansion in a case when is not
needed. However, it fails in fulfilling the whole modulo variable expansion
procedure, covering in this way the possibly incorrect behavior described above.
regards,
Alex
