Hello,
On 19.07.2012 13:14, Alex Turjan wrote:
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?
The dependencies that get removed with -fmodulo-sched-allow-regmoves are
only register ones, and with the check for setting REG_P in
schedule_reg_moves we are not supposed to touch memory.
I suggest you to look at the trunk's code as it was rewritten by Richard
Sandiford (CC'd), he could comment more on how the scheduling of register
moves was changed. See also the thread starting at
http://gcc.gnu.org/ml/gcc-patches/2011-08/msg02428.html.
Andrey
Alex
--- On Thu, 7/19/12, Andrey Belevantsev wrote:
From: Andrey Belevantsev Subject: Re: SMS issues To:
"Alex Turjan" Cc: gcc@gcc.gnu.org,
ayal.z...@gmail.com, revital.e...@linaro.org, "Roman Zhuikov"
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
