On Tuesday 17 March 2009 14:18:13 Scott Wood wrote:
Mike Frysinger wrote:
if C code is doing ptr checks, the compiler should make sure that pointer is not dereferenced at all if the hardware cannot suffer the consequences, even speculatively.
There is no reasonable way for the compiler to prevent such speculative accesses. Non-memory-like mappings must have the guarded bit set. That is what the bit is there for.
if the hardware doesnt have a way of preventing it, then the compiler must nop bad accesses that are unknown.
The hardware *does* have a way of preventing it. It's the guarded bit. :-)
I don't know of any amount of "nop" instructions that would be architecturally guaranteed to avoid this -- they're no-ops, not syncs (despite how some other architectures use them). They can be discarded as fast as the chip can decode them.
right, it depends on the pipeline. some let the nops force the address decode stages to get filled so they dont get speculatively filled and then fetched. sounds like the ppc pipeline doesnt operate that way.
Adding an isync instruction should avoid it, but that's a heavy performance penalty. Why pay it for all accesses rather than just those which are not memory-like (and can be flagged as such in the TLB)?
right, if the mappings allow speculative fetches to be turned off for certain regions, that's the way to go
i'm not sure your example proves your position. if you have a region that cannot stand speculative access, how do you handle bad pointer checking if the compiler may generate code that'll speculatively hit it at any time ?
The compiler is not speculatively doing anything. It is the CPU -- and the guarded bit tells it to not do that.
i didnt mean the compiler was doing it. i meant the compiler generates dense code that the hardware turns around and speculatively loads.
the change sounded like you were addressing a specific issue that was noticed, but other regions could still (in general) cause problems. but i guess that isnt the case at all.
thanks for the info -mike