[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: SMS issues
From:       Andrey Belevantsev <abel () ispras ! ru>
Date:       2012-07-23 9:04:37
Message-ID: 500D13A5.6070201 () ispras ! ru
[Download RAW message or body]

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 <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
>>>
>>
>>

[prev in list] [next in list] [prev in thread] [next in thread]