[fpc-devel] More peephole
Florian Klämpfl
florian at freepascal.org
Thu Jan 23 21:04:57 CET 2014
Am 23.01.2014 20:52, schrieb 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 consider it as complicated and it covers only cases one can forsee.
Some statistical analysis of benchmark timings and procedure sizes is
imo much more general.
>
> 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 - fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
More information about the fpc-devel
mailing list