[fpc-devel] I'll be straight

[Jonas Maebe]

On 09/02/19 08:33, J. Gareth Moreton wrote:

> In the last patch that Jonas almost immediately closed, the speed 
> savings were inconclusive because the number of cycles saved is probably 
> only a few dozen, but I would argue it makes the code a bit more 
> reasonable too because it replaces things like loc[low(loc)] with loc[0] 
> and fillchar with a for-loop that initialises each element of an array 
> to zero (it's slightly faster because the element size is a multiple of 
> 16, while fillchar is general-purpose and spends a lot of time jumping 
> around and even performing a multiplication before it starts filling 
> things up).  I guess seeing it marked as "won't fix" within 20 minutes 
> was a moment of horror.

When it comes to the compiler, I'm indeed usually inclined to the "if it 
ain't broken, don't fix it" school of thought. There are already plenty 
of things that break when necessary changes are performed, so why risk 
more breakage by minor touch-ups? As an aside, I also disagree that 
loc[low(loc)] is unreasonable. I consider it defensive programming. That 
said, since the convention is far from followed throughout all of that 
code, removing it doesn't make things really worse either.

That said, it is true that the parameter classification code for x86-64 
is quite complex and probably takes a lot of time. Additionally, 
sometimes we even calculate the parameter layout for the same type two 
times in a row (first in push_addr_param, and then again if that one 
returned false).

I think a better way to tackle this would be to add a small cache 
(possibly just an array of 10 elements that is searched linearly; a hash 
table risks spending more time and memory/cache flushing on maintaining 
the table than gaining from it) that keeps track of recently requested 
parameter layouts. This would have a potentially much bigger impact, and 
at the same time would not require fiddling with the internals of the 
existing code.

> I just want to avoid working on something, building passion for it which 
> is an unfortunate character flaw of mine, and then seeing it rejected or 
> ignored when it's finished.

I understand this is annoying. I realise that I am rather conservative 
in this respect. While I think I have good reasons for this stance 
(having spent a lot of time on fixing bugs added by other people while I 
wanted to work on my own stuff; not that other people have never been 
blocked by bugs I added, of course), it also bothers me that I 
discourage new contributors with this attitude.

> I've just hit a couple of impasses since I'm waiting on the node dump 
> feature to be approved and the status of the optimiser overhaul (I tend 
> to be quite good at doing peephole optimisations... at least a peephole 
> optimisation was the very first piece of code I submitted to FPC).

That's also how I started on FPC in 1997 :) But yes, it definitely was 
much easier back then to jump right in, because there were way fewer 
barriers to getting your code included. At the same time, we paid a 
hefty price for that for many years after that (from copyright issues to 
cleaning out hacks).


Jonas