[fpc-devel] More peephole

Florian Klämpfl florian at freepascal.org
Thu Jan 23 20:35:20 CET 2014


Am 22.01.2014 23:22, schrieb Martin Frb:
> On 22/01/2014 21:29, Florian Klämpfl wrote:
>> Am 22.01.2014 04:06, schrieb Martin Frb:
>>> On 21/01/2014 21:28, Florian Klämpfl wrote:
>>>> Can you post some example code? It might be worth to think about
>>>> improving this already in at the node level.
>>>>
>>> While getting examples, another issue:
>>>
>>>
>>> with -O2 , -O3 or -O4
>>>
>>> Note the
>>>      movl    %eax,%edx
>>>      movl    %edx,%eax
>>>
>>> with -O1 it is
>>>      movl    %eax,-4(%ebp)
>>>      movl    -4(%ebp),%eax
>> Well, -O1 can be neglected ...
>>
> 
> Ok.
> 
> There is another idea, I had in that context, and like to bring up.
> Though maybe this is already solved in a different way.
> 
> One of the optimizations you said it where better avoided to be created
> in first. I agree.
> Only, even if that is archived at some time, who guarantees that it will
> not be back (and unnoticed)?
> 
> Are there tests, that can detect this?

Not really, this is something I'am thinking about already for years :(

> Of course all generated assembler could be parsed back, and analysed.
> But that is rather a lot of work.

Yes.

> 
> Or the code could be added, and asserted not to be triggered. Of course
> adding actual test code to the compiler is not a good way either. Unless
> assert style / Only compiled in if -Sa or -dXXX is given.
> 
> Would anything in that direction make sense?

I think this is hard to achive as well.

> Then the code could work in real live, until no longer needed, at which
> time it was still useful for assertion.

Probably the best way would be benchmarking regarding runtime and
procedure size: significant changes in runtime or procedure size would
trigger an alert.



More information about the fpc-devel mailing list