[fpc-devel] More peephole

Martin Frb lazarus at mfriebe.de
Thu Jan 23 20:52:25 CET 2014

On 23/01/2014 19:35, Florian Klämpfl wrote:
> Am 22.01.2014 23:22, schrieb Martin Frb:
>> 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 :(
>> 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.


I see 2 scenarios. The peephole optimization is either
- always present (even if never triggered.

Then there is
asml.insertbefore(tai_comment.Create(strpnew('BAD_TEST_TRIGGERED')), p);

For the test, the compiler needs to be build with the define.
Then it runs with -al   ( [1] it can build al testcases, or even the 
compiler units, or rtl units / and there can be dedicated been written 
units to be compiled)
The assembler in grepped for BAD_TEST_TRIGGERED, it MUST NOT be found.

[1] The test is not complete, but it is impossible to feed every 
thinkable input, as that is an infinite amount. However compiling a huge 
amount of units gives a good chance of catching violations.

I might be overlooking something, but it should not be so hard.
For readability those optimization can either be in an include fileso 
there will be lines like

Or it can be in a separate function, running an extra loop, at the end 
or begin of the peephole pass.

More information about the fpc-devel mailing list