[fpc-devel] Potential whole program optimization

[J. Gareth Moreton]

I mention WPO because of other procedures calling them.  It would be 
very impractical to go back to procedures that have already gone through 
the peephole optimizer etc and change the references, especially if said 
reference is converted into a raw offset (I'm not absolutely sure when 
it's converted into a raw offset and when it's a reference that's 
converted by the assembler).

Gareth aka. Kit

On 19/07/2021 00:37, Martin Frb via fpc-devel wrote:
> On 19/07/2021 01:24, J. Gareth Moreton via fpc-devel wrote:
>>
>> The final assembly language of each method is identical.
>>
>> (Note that the trunk is not this efficient just yet... it still 
>> leaves a "movq %rcx,%rax" instruction prior to "movl $1,%r8d" and 
>> then calls "movq (%rax),%rax" instead of "movq (%rcx),%rax" - it's 
>> still all identical though).
>>
>> Would it be plausible to calculate and store a form of message digest 
>> (hash) of the final form of the tai entries or machine code and 
>> identify collisions and potential duplicate procedures for 
>> whole-program optimization? Granted I don't know anything about WPO 
>> yet so I don't know how plausible this is.  This wouldn't be 
>> somethind done on quick or debug builds because you'll need to be 
>> able to do proper stack traces, and having identical procedures 
>> merged into one might cause confusion.
>
> Why WPO?
>
> When you compute this hash, you could immediately check if it already 
> exists. (either in this unit, or any unit used).
>
> The only miss would be, if 2 units, that do not see each other include 
> identical code. That part could then still be a WPO.
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>

-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus