Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2019-08

Maintainability

3 messages · 2 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

J. Gareth Moreton

Hi everyone,

This is a bit of a nebulous question, but when might something be considered unmaintainable and hence rejected? For example, with my x86_64 optimiser overhaul, I've tried to make the code as straightforward as possible, but there are a few questionable tricks because one of my design restrictions was that -O1 and -O2 must not perform any worse than before, which was a bit difficult because pass 1 used to be executed twice no matter what (the one that stands out is how OptPass1MOV calls OptPass1XOR so it doesn't miss out on any optimisations with multiple concurrent MOV operations).  Might the restriction be waived if the resultant code became simpler?

There were other little ones like TransferUsedRegs - originally I had a version where you could choose to only transfer one set of registers (e.g. the integer registers) instead of all of them (which is a little costly), but there was concern that it might cause maintainability problems, possibly because of an optimisation playing with more than one type of register, for example.  Nevertheless, TransferUsedRegs also calls "Create" as a regular method, but I do my best to explain what's going on with comments.

Gareth aka. Kit

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

Reply by email

Florian Klämpfl
to J. Gareth Moreton
J. Gareth Moreton wrote 12 lines
Hi everyone, This is a bit of a nebulous question, but when might something be considered unmaintainable and hence rejected? For example, with my x86_64 optimiser overhaul, I've tried to make the code as straightforward as possible, but there are a few questionable tricks because one of my design restrictions was that -O1 and -O2 must not perform any worse than before, which was a bit difficult because pass 1 used to be executed twice no matter what (the one that stands out is how OptPass1MOV calls OptPass1XOR so it doesn't miss out on any optimisations with multiple concurrent MOV operations).  Might the restriction be waived if the resultant code became simpler?

IMO yes. If the code with -O1 or -O2 gets worse in a few cases, it doesn't matter. -O3 and -O4 are relevant for the best code.

Reply by email

J. Gareth Moreton
to Florian Klämpfl

Oh... well in that case, I can potentially make some code changes to make it simpler and faster!  Will probably increase the chances of it getting accepted!

Gareth aka. Kit

Florian Klämpfl wrote 21 lines
Am 11.08.19 um 20:15 schrieb J. Gareth Moreton: > Hi everyone, > > This is a bit of a nebulous question, but when might something be > considered unmaintainable and hence rejected? For example, with my > x86_64 optimiser overhaul, I've tried to make the code as > straightforward as possible, but there are a few questionable tricks > because one of my design restrictions was that -O1 and -O2 must not > perform any worse than before, which was a bit difficult because pass > 1 used to be executed twice no matter what (the one that stands out > is how OptPass1MOV calls OptPass1XOR so it doesn't miss out on any > optimisations with multiple concurrent MOV operations).  Might the > restriction be waived if the resultant code became simpler? IMO yes. If the code with -O1 or -O2 gets worse in a few cases, it doesn't matter. -O3 and -O4 are relevant for the best code. _______________________________________________ fpc-devel maillist  -  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

Reply by email