[fpc-devel] More peephole

[Martin Frb]

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.
>

Why?

I see 2 scenarios. The peephole optimization is either
- always present (even if never triggered.
- contained in $IFDEF BUILD_WITH_TEST_ASSERT

Then there is
   {$IFDEF BUILD_WITH_TEST_ASSERT{
asml.insertbefore(tai_comment.Create(strpnew('BAD_TEST_TRIGGERED')), p);
{$ENDIF}

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
{$DEFINE TEST_INCLUDE_PART_FOO} {$I TEST_INCLUDE}

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