[llvm-commits] [PATCH] Support for instruction cache flushing on Windows

[Aaron Ballman]

On Mon, Sep 19, 2011 at 1:53 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote:
> Aaron, I am sorry for long delay.
>
> 2011/8/26 Aaron Ballman <aaron at aaronballman.com>:
>> On Windows, there was no implementation for
>> llvm::sys::Memory::InvalidateInstructionCache, which I've rectified
>> with this patch.  Tested with Visual Studio 2010 and MinGW, though I
>> will admit that it shows no functional differences on my particular
>> hardware.  That doesn't mean it won't be useful on other hardware
>> though.
>
> In fact;
>
>  - x86 and x86-64 does not need explicit icache flushing on its
> microarchitecture.

As I understand it, a jmp is sufficient to flush the cache on x86-64,
and I would suppose that the call to
llvm::sys::Memory::InvalidateInstructionCache would take care of the
problem.  My worry is the compiler optimizing away the call to an
empty function, thereby missing the jmp it provided.

>  - in llvm::sys::Memory::InvalidateInstructionCache(),
>    no operations would be executed on any x86-based hosts.

Actually, an operation is executed -- the jmp itself.
<http://blogs.msdn.com/b/oldnewthing/archive/2003/12/08/55954.aspx>

> FYI, you should not give GetModuleHandle(NULL), but
> GetCurrentProcess() to 1st argument of FlushInstructionCache(). As an
> implementation, GetModuleHandl(NULL) represents virtual base addr of
> the process (eg. 0x00400000) and GetCurrentProcess() does the magic
> number (eg. 0xFFFFFFFF).

They can be use interchangeably so often, it's difficult to tell when
one is appropriate vs the other.  Good catch!  If you think the patch
may make sense (in light of the current conversation), I'll happily
fix it up.  If you still think it's not needed, then the issue is
moot.

Thanks!

~Aaron