This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Clarification Req: Regarding "memory" clobber for cache operation is required (?)


Hello,

Thanks a lot for your clarification! (and your time)
I have a doubt in the following response.

-------
> > P.S: I have checked the linux source. Looks
neither
> >      "memory" clobber nor any memory constraint is
> >      specified in inline asm for similar
operations
> >      in linux source.
> 
> It looks like the linux sources use volatile instead
> of memory clobbers.  Volatile is a stronger 
> statement than a memory clobber.
-------

Looks the "volatile" doesn't fullfil the purpose of
"memory" clobber and memory constraint. It looks like
just avoid reordering the inline asm instructions,
as part of optimization (please correct me if I am
wrong)

I have tested it with a small testcase (given below). 

<<<<< START copy.c >>>>>

static inline void copy_inline(char *dst, char *src,
int size)
{
    char temp;
    asm volatile ("0:   subu    %3,%3,1   \n"
                  "     bltz    %3, end   \n"
                  "     lbu     %0, 0(%2) \n"
                  "     sb      %0, 0(%1) \n"
                  "     b       0b        \n"
                  "end:"
                  : "=&r" (temp)
                  : "r" (dst), "r" (src), "r" (size));

     /* NOTE: "memory" clobber is not used here, but
              supposed to be used eventhough
              "volatile" is specified (?). */
}

int test ()
{
    char source[10] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
};
    char dest[10] = { 0 };
    char *ptr = &dest[9];  /* 'ptr' points to last 
                              element of 'dest[]' */
    *ptr = 0;
    copy_inline (dest, source, 10);
    if (*ptr != 9)
        return 0; /* Failure */
    return 1;
}
<<<<< END copy.c >>>>>

Generated .s file (given below) for the above testcase
with the following options

  Options          : -O2 -S
  Compiler Version : 2.95.3 (for mips-III arch)

<<<<< START copy.s (comments inlined) >>>>>

        <snipped>

        .globl  test
        .text
        .ent    test
test:
        .frame  $sp,88,$31  # vars= 32, regs= 3/0,
                            # args= 32, extra=0
        .mask   0x80030000,-8
        .fmask  0x00000000,0
        subu    $sp,$sp,88
        lui     $2,%hi($LC0) # high
        sd      $17,72($sp)
        addu    $17,$sp,32
        sd      $16,64($sp)
        addu    $16,$sp,48
        sd      $31,80($sp)
        addiu   $6,$2,%lo($LC0)
        ldl     $3,0($6)
        ldr     $3,7($6)
        lb      $4,8($6)
        lb      $5,9($6)
        sdl     $3,32($sp)
        sdr     $3,39($sp)
        sb      $4,40($sp)
        sb      $5,41($sp)
        move    $4,$16
        move    $5,$0
        .set    noreorder
        .set    nomacro
        jal     memset
        li      $6,10                   # 0xa
        .set    macro
        .set    reorder

        li      $2,10                   # 0xa
        sb      $0,57($sp)
 #APP
        0:      subu    $2,$2,1
        bltz    $2, end
        lbu     $3, 0($17)
        sb      $3, 0($16)
        b       0b
end:
 #NO_APP
        ld      $31,80($sp)
        ld      $17,72($sp)
        ld      $16,64($sp)
        move    $2,$0

==> Always returns 0. Expected behaviour is, *ptr
    should not be cached (or assumed as 0) as it is 
    being changed in copy_inline().

    If "memory" clobber is used in the inline asm,
    then it loads the *ptr from memory just before
this
    line and compares it with '9' as expected.

        .set    noreorder
        .set    nomacro
        j       $31
        addu    $sp,$sp,88
        .set    macro
        .set    reorder

        .end    test

<<<<< END copy.s >>>>>

Another question is, can we use the following like
constraints instead of using more costlier "memory"
clobber?

----------
typedef char helper [DCACHE_LINE_SIZE];
...
...

inline void invalidate_cache_line(void *ptr)
{
   asm volatile ("cache 17, 0(%1)"
                 : "=m" (*(helper *)ptr)
                 : "r" (ptr));
}

Please share your thoughts.

Thanks,
Ashok

--- Jim Wilson <wilson@specifixinc.com> wrote:
> On Thu, 2004-03-25 at 22:34, Ashok.A wrote:
> > To invalidate a cache line, do we really need to
> > use "memory" clobber in inline asm?
> 
> This is a difficult question to answer.
> 
> If it does not work without the memory clobber, then
> obviously you need
> it.
> 
> If it does appear to work without the memory
> clobber, then whether you
> need it depends on the context and how the asm is
> written, and possibly
> on what gcc versions you have and what compiler
> optimizations are
> enabled.  There is no simple answer here, other than
> to say that you are
> safer with a memory clobber than without one.
> 
> You don't need the memory clobber if you use an
> alternative method for
> describing the dependencies.  For instance, if you
> make the asm
> volatile.  Or if you have memory input(s) with size
> and address that
> covers the cache line being invalidated.
> 
> You don't need the memory clobber if you are sure
> that the function that
> contains the asm will never contain any memory
> references that will
> conflict with the cache line that is being
> invalidated.  (And the
> function is not marked inline or you are not
> compiling with
> -finline-functions, etc.)
> 
> Personally, I would include the clobber, or better
> yet, make the asm
> volatile.
> 
> > P.S: I have checked the linux source. Looks
> neither
> >      "memory" clobber nor any memory constraint is
> >      specified in inline asm for similar
> operations
> >      in linux source.
> 
> It looks like the linux sources use volatile instead
> of memory
> clobbers.  Volatile is a stronger statement than a
> memory clobber.
> -- 
> Jim Wilson, GNU Tools Support,
> http://www.SpecifixInc.com
> 


__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]