[fpc-devel] Kit's ambitions!

[J. Gareth Moreton]

 Would you object to me trying anyway, Florian? It might be that I run into
the same problems you had and it's too unsafe, but I'm going by a
conservative philosophy in that if it spots something that it can't work
out (e.g. an instruction that it's not programmed to handle) or is
potentially unsafe (e.g. reading and writing to a block of memory that it
doesn't have control over, due to multi-threading issues), then it just
stops optimising and drops all assumptions that it has made at that point.

 As a small test case, I'm attempting to see if I can spot and optimise,
for example, "mov %rax, %rbx; lea %rcx, -8(%rsp); mov %rbx, 8(%rsp)", where
a pipeline stall occurs due to a read-after-write penalty (with %rbx in
this case).  Normally the peephole optimiser will sort out such a problem,
but because LEA appears in between the MOV's, it won't catch it.  The
other thing is attempting to merge unsigned division and modulus into a
single "div" operation - that was actually my intention behind
"Minor_div_improvement" in issue #32984 - by changing SBB to SETAE, it
preserves the flags register that I can make better use of it in such a
deep optimiser, as I can be certain as to what its value is at that point
(or at the very least know it hasn't changed).
 More than anything, it's a personal research project - I'd be over the
moon if it works and it holds up to every test case thrown at it, but if it
doesn't, well, at least I know more about assembly language and have gained
experience to improve the peephole optimiser and other elements of FPC.

 Gareth aka. Kit

 On Mon 21/05/18 20:44 , Florian Klämpfl florian at freepascal.org sent:
 Am 13.05.2018 um 21:02 schrieb Christo: 
 > On Sun, 2018-05-13 at 03:28 +0100, J. Gareth Moreton wrote: 
 >>  Expand on Data Flow Analysis in the compiler. 
 >> 
 >> What I personally call the "Deep Optimizer", I'm proposing an
assembler-level optimisation 
 >> system (although it won't touch pure assembler routines) that
rearranges commands and changes 
 >> registers in order to minimise pipeline stalls and to also collapse a
"div" and "mod" 
 >> operation into a single instruction where possible.   
 > 
 > I would also like the data flow analyzer to look at inline assembler and
emit hints and warnings 
 > if it picks up something incoherent. 

 We had already a data flow analyzer for assembler in 1.0.x and early 2.x
times, however, it was 
 disabled after several years as it was too hard to make it work safely. 
 _______________________________________________ 
 fpc-devel maillist - fpc-devel at lists.freepascal.org [1] 
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[2]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel 

 

Links:
------
[1] mailto:fpc-devel at lists.freepascal.org
[2] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20180521/01120d5b/attachment.html>