Re: FOR loops running backwards
From: Martin Harvey (Demon Account) (martin_at_pergolesi.demon.co.uk)
Date: 11/01/03
- Next message: Martin Harvey (Demon Account): "Re: Buffer overrun 'exploit' example"
- Previous message: Martin Harvey (Demon Account): "Re: FOR loops running backwards"
- Maybe in reply to: Martin Harvey (Demon Account): "Re: FOR loops running backwards"
- Next in thread: Maarten Wiltink: "Re: FOR loops running backwards"
- Reply: Maarten Wiltink: "Re: FOR loops running backwards"
- Reply: Dr John Stockton: "Re: FOR loops running backwards"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 31 Oct 2003 23:38:39 +0000
On Thu, 30 Oct 2003 12:42:04 +0000, Dr John Stockton
<spam@merlyn.demon.co.uk> wrote:
>Read the FAQ more carefully.
I have. It's not sufficiently clear on this point, and in fact, I
suspect the FAQ writer didn't appreciate the subtleties involved.
>In this case, if "whatever" refers only to the current element, the
>order of operation is unimportant.
Rubbish. Well mostly - your second caveat is not sufficiently general.
It's easy for you to say "only looking at the current element", but
the compiler doesn't work in those terms - it's looking to see where
the index is used as an lvalue or an rvalue, and the subsequent usage
of those values.
I initially thought that you could apply the optimisation when:
- No external code is called in the loop.
- The loop index is not used to generate an rvalue, directly or
indirectly in the loop.
- The loop index may be used to generate lvalues.
I assumed for those premises that the compiler does not keep track of
which operations are order invariant.
However, even that is broken. Consider this:
MyRec = record a,b:integer; end;
MyArray = array[LowLim..HighLim] of MyRec;
MyInt:integer;
var
X:MyArray;
begin
for MyInt := LowLim to HighLim do
Inc(X[MyInt].a, X[MyInt].b);
end;
Looks safe as houses, right?
'fraid not! Think of it like this:
begin
try
for MyInt := LowLim to HighLim do
Inc(X[MyInt].a, X[MyInt].b);
except
on EOverflow do //access the array?
end;
end;
Oh dear!!!!
So we have a whole load of extra provisos:
- The loop may not generate an exception at any point.
- if the index is used as an rvalue, then all subsequent operations
using that rvalue must be commutative and associative.
Hmmm ... but at this point the plot thickens. You need to start doing
things like:
a) Have a set of rules (that follow the grammar and syntax of the
language) on what operations are order insensitive.
b) Have set of rules indicating what scope things can be modified
with.
c) If exceptions can be raised, have rules that none of the quantities
modified in the loop can be accessed from the exception handler
(otherwise disallow the optimisation)
d) as implied by c, this means that the loop omitisation can only be
applied if it only accesses local variables - who knows what
exceptions the caller might handle.
Oooh er ... gets rather tricky doesn't it?
I'm off to try and break my delphi compiler :-) If I succeed, then
it's a post to the Borland NG's. If I fail, then it's a post to
comp.compilers!
MH.
- Next message: Martin Harvey (Demon Account): "Re: Buffer overrun 'exploit' example"
- Previous message: Martin Harvey (Demon Account): "Re: FOR loops running backwards"
- Maybe in reply to: Martin Harvey (Demon Account): "Re: FOR loops running backwards"
- Next in thread: Maarten Wiltink: "Re: FOR loops running backwards"
- Reply: Maarten Wiltink: "Re: FOR loops running backwards"
- Reply: Dr John Stockton: "Re: FOR loops running backwards"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|