<div dir="ltr"><div>"2) Reporter's assumption about fstp is wrong: the first fstp instruction
removes value from fpu stack, so it cannot be used for the second time
without first reloading value onto stack."<br><br></div>Compiler should reuse loaded value (a[i]) and store to a[i] using fstl, then fstpl to a[i+1]</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 24, 2014 at 12:26 AM, Sergei Gorelkin <span dir="ltr"><<a href="mailto:sergei_gorelkin@mail.ru" target="_blank">sergei_gorelkin@mail.ru</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">24.01.2014 3:04, Martin Frb пишет:<div><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 23/01/2014 22:26, August Oktobar wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello, I have seen your mails about peephole optimization, so I wonder if you could look at this<br>
reports<br>
<a href="http://bugs.freepascal.org/view.php?id=23595" target="_blank">http://bugs.freepascal.org/<u></u>view.php?id=23595</a><br>
<br>
or perhaps optimize slow array access using operator [] (it is faster to use pointer arithmetics)<br>
<br>
thanks!<br>
</blockquote>
<br>
1) I am just getting started on this, so I can only answer with limited knowledge.<br>
@experts, please correct me below, where needed<br>
2) The peephole opt is only something I do "on the side" as it currently is.<br>
<br>
From a quick glance, this does not look like something for the peephole opt.<br>
<br>
The peephole opt currently looks at statements that are close together (follow each other immediately).<br>
I am not sure to which extend (if at all) it would be acceptable to break that limit (it is doable,<br>
question is if desired).<br>
<br>
In this specific case:<br>
1) between the "fstpl" and the "mov (half_the_data), %edi" are other statements.<br>
detecting the connection would either:<br>
- need scanning several statements ahead. This would be slow, because it had to be done after<br>
each storing "something to memory" (so very often)<br>
- keeping state of all the involved registers and memory (do-able / interesting at least from a<br>
theoretical view / but not sure if desired)<br>
2) only half the mem is accessed, and then the other half. That means to detect the connection<br>
between the mem read and the register, it is needed to analyse 4 statements. Very unlikely to see<br>
this in the peephole opt.<br>
<br>
The livelihood of "a[i]" needs to be checked where the code is generated.<br>
<br>
</blockquote>
<br></div></div>
1) You are right that it's not the job for peephole analyzer, it is typical common subexpression elimination.<br>
2) Reporter's assumption about fstp is wrong: the first fstp instruction removes value from fpu stack, so it cannot be used for the second time without first reloading value onto stack.<br>
3) The assignments of floating-point values are currently being generated using integer instructions, hence the subsequent code. This way it doesn't depend on number of available FPU registers, which is hard to know at any point.<br>
<br>
Regards,<br>
Sergei<br>
______________________________<u></u>_________________<br>
fpc-devel maillist - <a href="mailto:fpc-devel@lists.freepascal.org" target="_blank">fpc-devel@lists.freepascal.org</a><br>
<a href="http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel" target="_blank">http://lists.freepascal.org/<u></u>cgi-bin/mailman/listinfo/fpc-<u></u>devel</a><br>
</blockquote></div><br></div>