[fpc-devel] x86_64 Optimizer Overhaul

J. Gareth Moreton gareth at moreton-family.com
Thu Dec 6 16:55:13 CET 2018


 I believed I've fixed the bug.  Thanks for your help.

 I had misunderstood one of the internal methods and, as a result, it
wasn't resetting the register allocation usage with each iteration of the
loop (and to add insult to injury, caused a memory leak!).  By sheer
coincidence, this wasn't a problem under Windows because of some additional
code that skipped over the function prologue, but got triggered under
Linux.

 I've updated all of the patch files in the bug report and added an
additional one, since one function in particular got a bigger rework than
everything else (overhaul-mov-refactor).

 I haven't had a chance to re-test the timings yet, although I've tried to
provide a couple of additional savings for -O1 and -O2.

 Gareth aka. Kit

 P.S. Note that the code is very messy with functions being split between
i386 and x86_64. This is for testing and control cases.  If x86_64 is
successful, I intend to remove the distinctions and have i386 and x86_64
share the same overhaul.  One platform at a time though!

 On Sun 02/12/18 23:21 , "Marģers ." margers.roked at inbox.lv sent:
 I run it no linux. Problem code part.

 type PLongData = ^TLongData;
       TLongData = array [0..100] of longint;

 function binarySearchLong ( sortedArray:PLongData; nLen,
toFind:longint):longint;
 var low, high, mid, l, h, m : longint;
 begin
     { Returns index of toFind in sortedArray, or -1 if not found}
     low := 0;
     high := nLen - 1;

     l := sortedArray^[low];
     h := sortedArray^[high];

     while ((l = toFind)) do
     begin
          mid := (low + high) shr 1;   { var "low" in register
r8d }
          m := sortedArray^[mid];

          if (m < toFind) then
          begin
               low := mid + 1;
               l := sortedArray^[low];

         { asm code generated
 -- with trunk
         lea     r8d,
[r11d+1H]                          
     mov  esi, r8d
 --end trunk
 -- with overhaul   it never set r8d to new value, but should
         lea     esi,
[r11d+1H]                          
 -- end  overhaul

         mov     r10d, dword
[rdi+rsi*4]                 
         jmp    
?_00144                                 

         }
          end else
          if (m > toFind) then
          begin
               high := mid - 1;
               h := sortedArray^[high];
          end else
          begin
             binarySearchLong:=mid;
             exit;
          end;
          
     end;

     if (sortedArray^[low] = toFind) then
     begin
          binarySearchLong:=low;
     end else
         binarySearchLong := -1; { Not found}
 end;

         ----- Reply to message -----
 Subject: Re: [fpc-devel] x86_64 Optimizer Overhaul
 Date: 2018. gada 2. decembris 23:32:36
 From:  J. Gareth Moreton 
 To:  FPC developers' list  Thanks for the feedback.  Do you have a
reproducible case, and does it fail on Linux or Windows?  I'll have a look
for the infinite loops in the meantime.   Gareth aka. Kit          
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20181206/96dca5c3/attachment.html>


More information about the fpc-devel mailing list