[LLVMbugs] [Bug 19076] New: [mips] Implementation of __cache_flush() should use synci where possible

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=19076

            Bug ID: 19076
           Summary: [mips] Implementation of __cache_flush() should use
                    synci where possible
           Product: compiler-rt
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: compiler-rt
          Assignee: unassignedbugs at nondot.org
          Reporter: daniel.sanders at imgtec.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

There is a better implementation of __cache_flush() available on MIPS32r2 and
MIPS64r2 that could be implemented. However the necessary 'synci' and 'jr.hb'
instructions aren't implemented in LLVM yet. The better implementation, uses a
series of synci instructions to flush the cache, then a 'sync' followed by a
jr.hb to create the necessary barriers.

Here is an untested version of the better implementation based on the assembly
that gcc emits for __builtin_clear_cache():
void __clear_cache(void* start, void* end)
{
const uintptr_t start_int = (uintptr_t) start;
const uintptr_t end_int = (uintptr_t) end;
if (begin == end)
     return;

// Discover the step needed for the synci instructions
uintptr_t inc;
     asm volatile ("rdhwr %0, $1" : "=r"(inc));
     if (inc == 0)
           return;

     // Round the start address downwards
     start_int &= ~inc;

     // Flush the region
     while (start_int < end_int) {
           asm volatile ("synci %0", :: "r"(start_int) : "memory");
           start_int += inc;
     }

     // Memory barrier
     asm volatile ("sync" ::: "memory");

     // Execution hazard and instruction hazard barrier
     // The jr.hb is the important instruction and could be used in place
     // of the jr instruction that returns from this function rather than
     // faking a return like this.
     asm volatile ("bal 1f\n\t"
                   "nop\n\t"
                   "1: addiu $31, $31, 12\n\t"
                   "jr.hb $31\n\t"
                   "nop\n\t" ::: "$31", "memory");
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140307/7000902d/attachment.html>