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