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 <a...@ispras.ru> wrote: > From: Andrey Belevantsev <a...@ispras.ru> > Subject: Re: SMS issues > To: "Alex Turjan" <atur...@yahoo.com> > Cc: gcc@gcc.gnu.org, ayal.z...@gmail.com, revital.e...@linaro.org, "Roman > Zhuikov" <zhr...@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 > > > >
