[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