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.
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
