Hi Florian,
Thanks for the response. I'm mostly referring to r44241 that introdues
GetNextInstructionUsingRegTrackingUse and some restrictions on more
expensive optimisations.
One thing I wanted to bring up is "RemoveCurrentP(p)" - I've been
avoiding its use because it calls GetNextInstruction, which can be an
expensive call, and a lot of the time, I already know what the next
instruction is at that point (hence the "p := hp1;" assignments that
appear after it). I figure it might class as a micro-optimisation
though and I can certainly see a call to "RemoveCurrentP(p)" being
safer, lest we accidentally leave p dangling. Can I recommend we split
this into two separate commands named "RemovePAndSetNext" and
"RemovePAndNil" or some such? The former would set p to
GetNextInstruction, while the latter would set p to nil. With the aid
of inlining and deadstore removal, if "p := hp1;" follows a call to
RemovePAndNil(p), then the setting of p to nil will be removed by the
optimiser.
Gareth aka. Kit
On 09/03/2020 16:06, Florian Klaempfl wrote:
Am 08.03.2020 um 15:54 schrieb J. Gareth Moreton:
Hi everyone,
I've been away for a few days so I haven't
been paying too much attention to the trunk,
but I've noticed some new changes to the x86-
64 peephole optimized that look interesting.
Can someone fill me in on what they're meant
to do and the motivation behind the
additions? This is just so I fully understand
what everything is doing and don't
accidentally overwrite something.
Which ones do you mean? Normally, I try to a add a reasonable commit
message.
_______________________________________________
fpc-devel maillist - [email protected]
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
_______________________________________________
fpc-devel maillist - [email protected]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
