Need advice on bounds checking approaches
Jeffrey A Law
law@cygnus.com
Tue Mar 28 09:48:00 GMT 2000
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.
> 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.
> In summary, there will be some small space advantage for any target
> that has special instructions that support bounds checking. For
> multiple-issue CPUs, the space advantage will come at the expense of
> runtime, because the checks would likely run faster if they were
> broken apart to improve scheduling. It should be easy enough to
> implement each and benchmark to quantify the difference, or even to
> implement both, and choose at compile time based on the value of
> `optimize_size'.
Well, I'm not 100% you'll see any significant optimization advantage
due to better scheduling -- it largely depends on how the compiler
treats the bounds checking instructions.
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.
jeff
More information about the Gcc
mailing list