fpc 3.1.1 on i386
-O3

function FOO: Boolean;  inline;
begin
   Result := FMem  nil;
end;
function BAR: TPItemT;
begin
   if FOO
   then Result := nil
   else Result := TPItemT(FMem.FirstItemPointer + (Index *
FItemSize.ItemSize));
end;

generates something like:

005EACF0 833A00 cmp dword ptr [edx],$00 005EACF3 0F95C0 setnz al
005EACF6 84C0 test al,al
005EACF8 7509 jnz +$09

Is that something that should be optimized away?

al represents the nz flag

test al,al restores the nz flag, to what it already is. hat seems pointless.

Martin Frb wrote on Tue, 19 May 2015:

I'm sure you can find 100's of examples like that when using inline. So yes, it's obviously a missed optimisation, but an x86 peephole optimisation to remove those two instructions is "dweilen met de kraan open" (mopping up water while leaving the tap running), and (as far as I'm concerned) a waste of time since exactly the same happens on all architectures as well (except for possibly those without flags).

Florian has some ideas about how to simplify the node tree so that they can be optimised better at that (higher) level, but that won't immediately solve this particular problem by itself (although it's a step in the right direction) and it won't be ready any time soon.

Jonas

I knew why I ask for optimization in general, and not at any specific place :)

I was more interested if (with any disregard to priority or importance)
1) it is a known issue
2) regarded as issue at all

Appears to be.