Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

Op 2019-06-27 om 15:12 schreef George Bakhtadze: Volatile (I assume you mean a C-like volatile) is usable in very rare special cases. Such as work with hardware buffers. (in embedded targets it is not that rare. E.g. variables/state shared between interrupts handlers and main program)

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

Florian Klaempfl schrieb am Sa., 29. Juni 2019, 15:52: > Am 28.06.2019 um 11:24 schrieb George Bakhtadze: > > This assumption is *not* incorrect. Only on the LLVM based Delphi > > NewGen and FPC's LLVM backend the assumption is incorrect which can > > be seen by them having added

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

Am 28.06.2019 um 11:24 schrieb George Bakhtadze: This assumption is *not* incorrect. Only on the LLVM based Delphi NewGen and FPC's LLVM backend the assumption is incorrect which can be seen by them having added "volatile" mechanisms. I believe this assumption incorrect because

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

George Bakhtadze schrieb am Sa., 29. Juni 2019, 09:32: > > > This assumption is *not* incorrect. Only on the LLVM based Delphi NewGen > and FPC's LLVM backend the assumption is incorrect which can be seen by > them having added "volatile" mechanisms. > > > I believe this assumption incorrect

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

 This assumption is *not* incorrect. Only on the LLVM based Delphi NewGen and FPC's LLVM backend the assumption is incorrect which can be seen by them having added "volatile" mechanisms.  I believe this assumption incorrect because it's not stated in documentation as correct.If FPC somehow

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

> As an side since you’re talking about optimizations what would it take to > make the copy/addref record operators be inline? Unless I’m mistaken that’s > one of the bigger issues that makes custom ref counted objects slower than > built in compiler types. Just curious... I believe counter's

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

George Bakhtadze schrieb am Fr., 28. Juni 2019, 08:26: > Hello, > > > One thing I have been considering is to promote fields and global > variables to local registers to reduce memory accesses. > > That would be great. But multithreaded code which assume (incorrectly) > that those fields and

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

Hello, > One thing I have been considering is to promote fields and global variables to local registers to reduce memory accesses. That would be great. But multithreaded code which assume (incorrectly) that those fields and globals are in memory may be broken.Other languages don't allow to assume

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

In the meantime, I have some optimisations that I would be grateful could be evaluated - two of them are specific to the compiler, but one is much more general-purpose, relating to case blocks. https://bugs.freepascal.org/view.php?id=34859 https://bugs.freepascal.org/view.php?id=35346

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

Am 27.06.2019 um 20:40 schrieb Ryan Joseph: As an side since you’re talking about optimizations what would it take to make the copy/addref record operators be inline? Unless I’m mistaken that’s one of the bigger issues that makes custom ref counted objects slower than built in compiler types.

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

As an side since you’re talking about optimizations what would it take to make the copy/addref record operators be inline? Unless I’m mistaken that’s one of the bigger issues that makes custom ref counted objects slower than built in compiler types. Just curious... Regards, Ryan Joseph

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

On Thu, Jun 27, 2019 at 8:15 AM Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > I think having record fields in registers would already go a long way. > Global variables aren't used /that/ often in modern, object oriented code > anyway. > Aren't they already?

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

J. Gareth Moreton schrieb am Do., 27. Juni 2019, 12:18: > One thing I have been considering is to promote fields and global > variables to local registers to reduce memory accesses. However, it would > make multi-threaded code a bit trickier to write and demand the use of the > "volatile"

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

One thing I have been considering is to promote fields and global variables to local registers to reduce memory accesses.  However, it would make multi-threaded code a bit trickier to write and demand the use of the "volatile" intrinsic on things like the conditions of while loops. Before I

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

Hi Gareth, there are more optimizations to look at An user could write custom string enumerators to replace such assignments in loops and try to manually solve that issue. But then https://bugs.freepascal.org/view.php?id=34915 the enumerators are stored in memory rather than registers, so

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

I figured you were serious with it.  I've garned a reputation, it seems! I have some organisation to figure out first, since I've got to fix a bug , begin development of pure functions and update my patches for the x86-64 optimiser overhaul so it

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

On Thu, 27 Jun 2019, J. Gareth Moreton wrote: https://bugs.freepascal.org/view.php?id=35775 I'm both honoured and amused!  Thank you. Well, it was meant seriously. You mentioned more than once that you like optimizations. This one would be a real big improvement for a pattern that is often