kniffliges Rätsel - Compileroptimierung

[haentschman]

Hallo alle...

...erst mal, das Konstrukt stammt nicht von mir:thumb:

Delphi-Quellcode:

function bla: Boolean
begin
    Result:= False
     for i = 0 to 10 do 
     begin
        if blabla then
           exit;
        if blabla1 then
           exit;      //X
     end;
     Result:= True;
end

Frage: warum wird das mit X gekennzeichnete wegoptimiert.

...bitte keine doofen Fragen. Ich muß mich damit quälen. Ist auch schon umgestellt. 8-)

[Bummi]

weil blablaimmer true ergibt, oder blabla1 nie true ergibt ?

[sx2008]

Das kann man auch so schreiben:

Delphi-Quellcode:

function bla: Boolean
begin
  for i = 0 to 10 do
  begin
    if blabla or blabla1 then
       Exit(False); // entspricht Result:=False; Exit;
  end;
  Result:= True;
end

Dadurch dass das Result (CPU-Register AX) nicht von Anfang an belegt wird,
kann der Kompiler (falls er smart genug ist) das Register für Zwischenergebnisse benützen.

[haentschman]

Sooo... endlich wieder ne vernünftige Tastatur unter den Fingern...:thumb:

In der Schleife wird ein String Zeichenweise geprüft. BlaBla und BlaBla1 sind Funktionen die auf vorhandene Zeichen prüfen. Diese funktionieren. Entweder True oder False.
PS: Dieses Phänomen habe ich auch schon an anderer Stelle, anderem Zusammenhang gesehen. Dabei betrifft das immer das letzte Exit. selbst ein begin/end Block ändert nix. Nur wenn man vor das letzte Exit im Block noch einen sinnlosen Befehl schreibt wird das Exit mit einkompilliert.

Merkwürden...:roll:

[Furtbichler]

Müsste man doch im Assembler sehen

Delphi-Quellcode:

i := 0;
1: if i>10 then goto 2;
   if blabla then exit
   inc(i);
   if not blabla1 then goto 1;
2:

Wäre es denkbar, das die For-Schleife so optimiert wird?

[haentschman]

:lol: Was willst du im Assembler sehen wenn das Exit nicht eincompiliert ist ? Ich habe einen, der das versteht, gucken lassen... Nach dem letzten Vergleich gehts direkt weiter.

[Furtbichler]

Zitat:

Zitat von haentschman (Beitrag 1202486)

:lol: Was willst du im Assembler sehen wenn das Exit nicht eincompiliert ist ?

Na ja, wo und wie blabla1 verwendet wird.:lol:

[haentschman]

Es war soviel zu sehen, daß das BlaBla1 True war und normalerweise der nächste Befehl das Exit sein sollte, was einfach nicht da war. Auch in der IDE konnte man keinen Breakpoint auf das Exit setzen. Kein Blauer Punkt und ungültiger Breakpoint.

Ich weis schon warum ich darum einen Bogen mache...:zwinker:

[p80286]

Ich verstehe Dein Problem nicht:

Code:

call blabla
test al,al
jnz +$18 ; spring nach ende entspricht exit
...
call blabla1
test al,al
jnz +$08  ; spring nach ende entspricht exit
...
xor eax,eax ;hier ist ende
pop ecx
...

Man könnte bemängeln, daß der Debugger nicht ordentlich funktioniert, mit optimieren hat das aber meiner Meinung nach nichts zu tun.

Gruß
K-H

[Sir Rufo]

Zitat:

Zitat von p80286 (Beitrag 1202518)

Ich verstehe Dein Problem nicht:

Code:

call blabla
test al,al
jnz +$18 ; spring nach ende entspricht exit
...
call blabla1
test al,al
jnz +$08  ; spring nach ende entspricht exit
...
xor eax,eax ;hier ist ende
pop ecx
...

Man könnte bemängeln, daß der Debugger nicht ordentlich funktioniert, mit optimieren hat das aber meiner Meinung nach nichts zu tun.

Gruß
K-H

jepp, das Kompilat ist ok, allerdings sind beim

Delphi-Quellcode:

Exit

keine blauen Punkte zum Markieren eines Haltepunkts.

So bekommt man die aber doch (ich habe jetzt nur mal ein WriteLn dazu geschrieben)

Delphi-Quellcode:

function bla: Boolean
begin
    Result:= False
     for i = 0 to 10 do 
     begin
        if blabla then
        begin 
          WriteLn;
          exit;
        end;
        if blabla1 then
        begin 
          WriteLn;
          exit; //X
        end;
     end;
     Result:= True;
end

[CCRDude]

Bei

Delphi-Quellcode:

if then

mit Anweisung in nächster Zeile sind die "blauen Punkte" oft nicht als Haltepunkt zu gebrauchen, weil sie komplett in der ersten Zeile arbeiten, das ist schon ewig so.

Bemängeln würde ich dies nicht, weil spätestens beim QA-Audit das

Delphi-Quellcode:

if x then dosomething;

zu einem

Delphi-Quellcode:

if x then begin dosomething; end;

würde/sollte (und das funktioniert bei mir im Debugger immer).

Zumindest bei uns ist das Pflicht, und ich glaube die QA-Audits, die Delphi anbietet (evtl. erst ab der Enterprise? bei mir sind die Menüpunkte gerade ausgegraut, verwende aber auch nur noch die Pro), bemängeln ein

Delphi-Quellcode:

if then

ohne

Delphi-Quellcode:

begin end;

ebenfalls.

[Sir Rufo]

Zitat:

Zitat von CCRDude (Beitrag 1202537)

Bei

Delphi-Quellcode:

if then

mit Anweisung in nächster Zeile sind die "blauen Punkte" oft nicht als Haltepunkt zu gebrauchen, weil sie komplett in der ersten Zeile arbeiten, das ist schon ewig so.

Bemängeln würde ich dies nicht, weil spätestens beim QA-Audit das

Delphi-Quellcode:

if x then dosomething;

zu einem

Delphi-Quellcode:

if x then begin dosomething; end;

würde/sollte (und das funktioniert bei mir im Debugger immer).

Zumindest bei uns ist das Pflicht, und ich glaube die QA-Audits, die Delphi anbietet (evtl. erst ab der Enterprise? bei mir sind die Menüpunkte gerade ausgegraut, verwende aber auch nur noch die Pro), bemängeln ein

Delphi-Quellcode:

if then

ohne

Delphi-Quellcode:

begin end;

ebenfalls.

Das hilft in diesem Falle aber nicht, denn bei

Delphi-Quellcode:

if foo then
begin
  Exit;
end;

gibt es auch keine blauen Punkte ;)

[CCRDude]

Hmmm interessant! Das scheint ein wenig vom Kontext abhängig. Siehe Anhang.

[haentschman]

Moin... 8-)

Schön, daß ihr die Zeit findet Euch damit zu beschäftigen. :thumb: Interessant ist das Thema allemal. Wenn man nicht explizit drauf achtet ist mal schnell was wegoptimiert von dem man ausgeht (logischerweise) daß es funktioniert... wer achtet schon wirklich auf die blauen Punkte :zwinker:

Der Knackpunkt liegt ja hier:

Delphi-Quellcode:

function bla: Boolean
begin
    Result:= False
     for i = 0 to 10 do
     begin
        if blabla then
        begin
          WriteLn;
          exit;
        end;
        if blabla1 then
        begin
          WriteLn;
          exit; // wird eincompiliert
        end;
     end;
     Result:= True;
end

zu:

Delphi-Quellcode:

function bla: Boolean
begin
    Result:= False
     for i = 0 to 10 do
     begin
        if blabla then
        begin
          WriteLn;
          exit;
        end;
        if blabla1 then
        begin
          exit; // wird nicht eincompiliert
        end;
     end;
     Result:= True;
end

...das kann wahrscheinlich nur der Programmierer der Optimierung des Compilers beantworten. :zwinker:

[CCRDude]

Es geht auch ohne das

Delphi-Quellcode:

WriteLn

, z.B. mit einem expliziten Returnwert.

Delphi-Quellcode:

function bla: Boolean;
begin
   Result := false;
   for i := 1 to 10 do begin
      if i = 5 then begin
         Exit;
      end;
      if foo then begin
         Exit(false); // hier gibt es eine Haltpunktmöglichkeit
      end;
   end;
   Result := true;
end;

Oder sobald Exception-Handling in's Spiel kommt:

Delphi-Quellcode:

function bla: Boolean;
begin
   Result := false;
   try
      for i := 1 to 10 do begin
         if i = 5 then begin
            Exit;
         end;
         if foo then begin
            Exit; // hier gibt es eine Haltpunktmöglichkeit
         end;
      end;
      Result := true;
   except
      Result := false;
   end;
end;

So oder so, wegoptimiert ist der Code nicht, sondern lediglich im Debugger nicht als Breakpoint verwendbar.