Re: SMS issues

[Andrey Belevantsev <abel at ispras dot ru>]

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