Re: Need advice on bounds checking approaches

[Greg McGary <gkm at eng dot ascend dot com>]

Geoff Keating <geoffk@cygnus.com> writes:

> By 'memory barrier', I mean an instruction over which it is not safe
> to move memory accesses.  It would be annoying if in the code sequence
> 
>    if (i > 10) trap;
>    a[i] = 3;
> 
> the store to the array was moved before the trap.

I'm not sure I agree that it's annoying to reorder bounds checks &
memory accesses.  What matters is that we get the trap for the bounds
violation, and that the bounds-violating code is identifiable from the
trap.  The order in which the check & associated memory reference
occurs is only a concern if you're going to somehow try and prevent or
alter the memory access on the basis of having gotten the trap.
That's way beyond what we're trying to do here.  If the memory access
gives us a SEGV, it doesn't matter whether or not the trap came
first--we still found the bug.  IF the memory access doesn't SEGV, the
trap will uncover the bug regardless of whether it comes before or
after the access.  Therefore, if the memory-barrier behavior for
bounds checks inhibits optimization in any meaningful then I think we
should drop the barrier semantics--it's not worth the cost.

Is there some other advantage to memory-barrier semantics wrt. bounds
checks that I'm overlooking?

Greg