Re: SMS issues

[Alex Turjan <aturjan at yahoo dot com>]

Andrey,
Thanks for the patch. I applied it and so far it seams ok.
I will run further testing and let you know if i see problems.

Back to the last part of my email, Im still wondering what happens in case
the variable modulo expanded is a memory location? because as I see generate_reg_moves is not able to handle such situation... or perhaps there is something which prevents the modulo scheduler from arriving to this situation?

Alex

--- On Thu, 7/19/12, Andrey Belevantsev <abel@ispras.ru> wrote:

> From: Andrey Belevantsev <abel@ispras.ru>
> Subject: Re: SMS issues
> To: "Alex Turjan" <aturjan@yahoo.com>
> Cc: gcc@gcc.gnu.org, ayal.zaks@gmail.com, revital.eres@linaro.org, "Roman Zhuikov" <zhroma@ispras.ru>
> Date: Thursday, July 19, 2012, 11:11 AM
> 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
> >
> 
>