Need advice on bounds checking approaches

[Geoff Keating]

> cc: Geoff Keating <geoffk@cygnus.com>, gcc@gcc.gnu.org
> Reply-To: law@cygnus.com
> Date: Tue, 28 Mar 2000 10:40:52 -0700
> From: Jeffrey A Law <law@cygnus.com>
> 
> 
>   In message < msem8vovhj.fsf@gkm-dsl-194.ascend.com >you write:
>   > Jeffrey A Law <law@cygnus.com> writes:
>   > 
>   > > Is there any advantage to not always emitting the high/low bounds checks
>   > > separately?
>   > 
>   > For i960 there's a small advantage that if you emit checks together,
>   > you can use concmp and save one instruction ("cmpo; concmpo; fault"
>   > vs. "cmpo; fault; cmpo; fault").  Big deal...
> That indicates to me that we have 3 primitives.
> 
>   1. check high bounds
>   2. check low bounds
>   3. check high and low bounds
> 
> When we generate code we should first check for the availability of #3, then
> fall back to #1 & #2, then fall back to whatever scheme we can devise using
> unconditional break/trap instructions or abort calls.

Note that you can do (3) with a subtraction and a single conditional
trap instruction---eg. if you want to check whether 'r3' is between 4
and 10, you can do

    tmp = r3 - 4
    if ((unsigned)r3 > 6)  trap;

or

    tmp = r3 - 4 + MIN_INT;
    if ((int)r3 > MIN_INT + 6)  trap;

depending on what's available.  The machine-independent code should be
able to work this out.

Of course, this only makes sense if a conditional trap is slower than
a subtraction, which is not the case on at least ppc (they are both
one cycle each).  If there are no conditional traps, probably
gcc should already be trying to do this for conditional branches.

>   > For i386, if you check both at once, you can use the `bound'
>   > instruction, which is slower, but very compact.
> That's easily handled by making the check high & low bounds instruction
> be conditional on optimize_size and provide additional patterns to theck
> the high bound and another pattern to check the low bound.

It certainly sounds like a good idea on x86 to have the use of the
'bound' insn conditional on optimize_size.

> For example, if the compiler treats them as ending the current basic block,
> then that's going to inhibit a lot of optimizations.  However, that might
> be necessary to prevent the compiler from over-optimizing in the presence
> of bounds checking instructions.  I don't really know.

They shouldn't end a basic block.  So long as the compiler knows that
'trap' RTXs are memory barriers, I think it can optimise them just
like any other insn; and I think that's what it now does.

-- 
- Geoffrey Keating <geoffk@cygnus.com>