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 _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
