Re: [fpc-devel] Progress on reviewing x86_64 optimizer overhaul and node semantic pass

2019-10-30 Thread George Bakhtadze
> For example, if I have changes in separate files that I want to split up, how 
> might one go about it without manually modiying the patch files? (As an easy 
> example, I split up the uComplex patches into two... one with the alignment 
> and vectorcall changes, and the other with the "const" modifier in the 
> parameters).

As an option, you can apply patches and create new ones with e.g. VCS->Create 
patch in IDEA where you can select which files and which changes within each 
file should go to the patch.

---
Best regards, George
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Progress on reviewing x86_64 optimizer overhaul and node semantic pass

2019-10-29 Thread J. Gareth Moreton

Thanks George,

As Florian stated, my work on the optimiser overhaul has been rejected 
because of how intertwined it is, along with some elements of 'code 
smell', but there's plenty to salvage and he hasn't slammed the door on 
the concept.  I'm still learning to use git and patches, especially with 
splitting up changes.  For example, if I have changes in separate files 
that I want to split up, how might one go about it without manually 
modiying the patch files? (As an easy example, I split up the uComplex 
patches into two... one with the alignment and vectorcall changes, and 
the other with the "const" modifier in the parameters).


I haven't heard anything regarding the node semantic pass yet.

Gareth aka. Kit

On 28/10/2019 17:29, George Bakhtadze wrote:
> Oh yeah, conflict resolution is the thing nobody really gets right, 
but TGit is

> a bit less wrong.
> I've pretty much resigned myself to Ctrl-F ">"...
I use Intellij IDEA as VCS client (both git and svn supported).
Patches, partial commits and conflicts resolution (automatic for many 
cases) are there.
Yes, it's not a git client but a fully featured IDE but as bonus, with 
a certain plugin it supports Pascal language. ;)
I hope it'll help to get these changes into codebase as patches 
improving compiled code performance are very important at least for me.

Thanks to Gareth for this work!
---
Best regard, George

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


Re: [fpc-devel] Progress on reviewing x86_64 optimizer overhaul and node semantic pass

2019-10-29 Thread George Bakhtadze
> Oh yeah, conflict resolution is the thing nobody really gets right, but TGit is> a bit less wrong.> I've pretty much resigned myself to Ctrl-F ">"... I use Intellij IDEA as VCS client (both git and svn supported).Patches, partial commits and conflicts resolution (automatic for many cases) are there. Yes, it's not a git client but a fully featured IDE but as bonus, with a certain plugin it supports Pascal language. ;) I hope it'll help to get these changes into codebase as patches improving compiled code performance are very important at least for me. Thanks to Gareth for this work! ---Best regard, George
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Progress on reviewing x86_64 optimizer overhaul and node semantic pass

2019-10-28 Thread Ewald
On 10/27/2019 08:16 PM, Martok wrote:
> Am 27.10.2019 um 17:48 schrieb Florian Klämpfl:
>>> I guess the main difference is whether one prefers side-by-side
>>> diffs or udiffs.
>>
>> In particular partial commits as well as conflict resolution work much 
>> better with TortoiseGit for me.
> 
> Oh yeah, conflict resolution is the thing nobody really gets right, but TGit 
> is
> a bit less wrong.
> I've pretty much resigned myself to Ctrl-F ">"...

Have you tried meld? Works for me in combination with git gui
-- 
Ewald
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Progress on reviewing x86_64 optimizer overhaul and node semantic pass

2019-10-27 Thread Michael Van Canneyt



On Sun, 27 Oct 2019, Martok wrote:


Am 27.10.2019 um 17:48 schrieb Florian Klämpfl:

I guess the main difference is whether one prefers side-by-side
diffs or udiffs.


In particular partial commits as well as conflict resolution work much 
better with TortoiseGit for me.


Oh yeah, conflict resolution is the thing nobody really gets right, but TGit is
a bit less wrong.
I've pretty much resigned myself to Ctrl-F ">"...


By the way, many people seem to use git on the client side... I remember there
were talks about moving the main repo to git. What happened to that?


Boring job nobody wants to do?


Haha, thought so :D


Not really. We will move to git after 3.2 is out. Moving now would interfere
with the release process too much.

Michael.___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Progress on reviewing x86_64 optimizer overhaul and node semantic pass

2019-10-27 Thread Martok
Am 27.10.2019 um 17:48 schrieb Florian Klämpfl:
>> I guess the main difference is whether one prefers side-by-side
>> diffs or udiffs.
> 
> In particular partial commits as well as conflict resolution work much 
> better with TortoiseGit for me.

Oh yeah, conflict resolution is the thing nobody really gets right, but TGit is
a bit less wrong.
I've pretty much resigned myself to Ctrl-F ">"...

>> By the way, many people seem to use git on the client side... I remember 
>> there
>> were talks about moving the main repo to git. What happened to that?
> 
> Boring job nobody wants to do?

Haha, thought so :D


Best,

Sebastian

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Progress on reviewing x86_64 optimizer overhaul and node semantic pass

2019-10-27 Thread Benito van der Zander

Hi,

I use TortoiseHg and then a Mercurial to Git converter...

Unfortunately the linux distributions do not want to maintain it and 
most ship with an outdated TortoiseHg in their package management


Best,
Benito

On 27.10.19 17:48, Florian Klämpfl wrote:

Am 27.10.19 um 15:32 schrieb Martok:
cover one single topic. Today, using e.g. TortoiseGit on Windows 
(sorry,

on Linux there is no tool which comes close) such patches can be
re-arranged without too much hazzle.


Just plain ol' git-gui can also do it. SmartGit is cross-platform and 
also
pretty nice. 


I use SmartGit on linux, but neither SmartGit nor git-gui come close 
to TortoiseGit for me.



I guess the main difference is whether one prefers side-by-side
diffs or udiffs.


In particular partial commits as well as conflict resolution work much 
better with TortoiseGit for me.





By the way, many people seem to use git on the client side... I 
remember there

were talks about moving the main repo to git. What happened to that?


Boring job nobody wants to do?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Progress on reviewing x86_64 optimizer overhaul and node semantic pass

2019-10-27 Thread Florian Klämpfl

Am 27.10.19 um 15:32 schrieb Martok:

cover one single topic. Today, using e.g. TortoiseGit on Windows (sorry,
on Linux there is no tool which comes close) such patches can be
re-arranged without too much hazzle.


Just plain ol' git-gui can also do it. SmartGit is cross-platform and also
pretty nice. 


I use SmartGit on linux, but neither SmartGit nor git-gui come close to 
TortoiseGit for me.



I guess the main difference is whether one prefers side-by-side
diffs or udiffs.


In particular partial commits as well as conflict resolution work much 
better with TortoiseGit for me.





By the way, many people seem to use git on the client side... I remember there
were talks about moving the main repo to git. What happened to that?


Boring job nobody wants to do?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Progress on reviewing x86_64 optimizer overhaul and node semantic pass

2019-10-27 Thread Martok
> cover one single topic. Today, using e.g. TortoiseGit on Windows (sorry, 
> on Linux there is no tool which comes close) such patches can be 
> re-arranged without too much hazzle.

Just plain ol' git-gui can also do it. SmartGit is cross-platform and also
pretty nice. I guess the main difference is whether one prefers side-by-side
diffs or udiffs.


By the way, many people seem to use git on the client side... I remember there
were talks about moving the main repo to git. What happened to that?


Best,

Sebastian

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Progress on reviewing x86_64 optimizer overhaul and node semantic pass

2019-10-26 Thread Florian Klämpfl

Am 26.10.19 um 16:47 schrieb J. Gareth Moreton:

Hi Florian,

That seems like a fair assessment.  I'll see what I can do, especially 
as I have a design spec to go by, so maybe there's stuff to salvage and 
re-implement.


If I recall, there was a similar TODO in the current code and it just 
got moved, but I'll double-check that.


I've seen 'goto' used a few times in the code but wasn't sure what the 
policy was on that.  Generally I use a "repeat... until True;" loop with 
a "Continue;" - is that an okay substitution?


Since you're suggesting more bite-sized chunks, I think the first thing 
I'll do is overhaul the jump optimisations, since they caused 
significant improvements in places that are independent of reducing the 
optimiser passes.


Yes. Those are indeed useful. Make yourself familiar how to do partial 
commits with TortoiseGit, this works very well: 
https://stackoverflow.com/questions/32527097/can-you-do-partial-commit-in-tortoisegit


In combination with rebasing you can quickly redo the patches to 
refactor out this part.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Progress on reviewing x86_64 optimizer overhaul and node semantic pass

2019-10-26 Thread J. Gareth Moreton
Still, if anything, contributing to the compiler like this and having 
patches rejected is teaching me to be a better coder, so thank you Florian!


Gareth aka. Kit


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

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Progress on reviewing x86_64 optimizer overhaul and node semantic pass

2019-10-26 Thread J. Gareth Moreton
Sorry, I meant a "repeat... until False;" loop, using "Break" or "Exit" 
statements when I actually want to leave it, and "Continue" for the 
'not-a-goto' statement!


On 26/10/2019 15:47, J. Gareth Moreton wrote:

Hi Florian,

That seems like a fair assessment.  I'll see what I can do, especially 
as I have a design spec to go by, so maybe there's stuff to salvage 
and re-implement.


If I recall, there was a similar TODO in the current code and it just 
got moved, but I'll double-check that.


I've seen 'goto' used a few times in the code but wasn't sure what the 
policy was on that.  Generally I use a "repeat... until True;" loop 
with a "Continue;" - is that an okay substitution?


Since you're suggesting more bite-sized chunks, I think the first 
thing I'll do is overhaul the jump optimisations, since they caused 
significant improvements in places that are independent of reducing 
the optimiser passes.


Gareth aka. Kit

On 26/10/2019 13:26, Florian Klämpfl wrote:

Am 18.10.19 um 18:07 schrieb J. Gareth Moreton:

Hi everyone,

How is everyone doing?  Sorry for my silence - been a bit tied up 
with things in life.  Anyway, that aside, has there been any further 
progress on reviewing the x86_64 optimizer overhaul over at 
https://bugs.freepascal.org/view.php?id=34628? I ask because I've 
sort-of blocked myself in any further improvements to the peephole 
optimizer.


I had meanwhile a look at it and to be honest, I am against applying 
the remainders in its current form.
- First, the patches are inter-winded and the single patches do not 
cover one single topic. Today, using e.g. TortoiseGit on Windows 
(sorry, on Linux there is no tool which comes close) such patches can 
be re-arranged without too much hazzle.
- Breaking the principle of the multiple optimizer passes is 
reasonable on the one hand, on the other hand it makes complicated 
code even more complicated and in particular as only the optimizer 
benefits, I see no reason to do so. In particular in combination with 
using gotos, the price being payed regarding maintainability is very 
high.
- Also things like ConditionalJumpShortcut in aoptx86.pas containing 
arm and aarch64 defines does not convince me regarding the patches.
- Patches contains open todo: "TODO: FIXME removing the first 
instruction fails"


I would really like to see parts of the patch applied, but this 
requires that it is re-arranged in small, oversee-able changes.

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


Re: [fpc-devel] Progress on reviewing x86_64 optimizer overhaul and node semantic pass

2019-10-26 Thread J. Gareth Moreton

Hi Florian,

That seems like a fair assessment.  I'll see what I can do, especially 
as I have a design spec to go by, so maybe there's stuff to salvage and 
re-implement.


If I recall, there was a similar TODO in the current code and it just 
got moved, but I'll double-check that.


I've seen 'goto' used a few times in the code but wasn't sure what the 
policy was on that.  Generally I use a "repeat... until True;" loop with 
a "Continue;" - is that an okay substitution?


Since you're suggesting more bite-sized chunks, I think the first thing 
I'll do is overhaul the jump optimisations, since they caused 
significant improvements in places that are independent of reducing the 
optimiser passes.


Gareth aka. Kit

On 26/10/2019 13:26, Florian Klämpfl wrote:

Am 18.10.19 um 18:07 schrieb J. Gareth Moreton:

Hi everyone,

How is everyone doing?  Sorry for my silence - been a bit tied up 
with things in life.  Anyway, that aside, has there been any further 
progress on reviewing the x86_64 optimizer overhaul over at 
https://bugs.freepascal.org/view.php?id=34628? I ask because I've 
sort-of blocked myself in any further improvements to the peephole 
optimizer.


I had meanwhile a look at it and to be honest, I am against applying 
the remainders in its current form.
- First, the patches are inter-winded and the single patches do not 
cover one single topic. Today, using e.g. TortoiseGit on Windows 
(sorry, on Linux there is no tool which comes close) such patches can 
be re-arranged without too much hazzle.
- Breaking the principle of the multiple optimizer passes is 
reasonable on the one hand, on the other hand it makes complicated 
code even more complicated and in particular as only the optimizer 
benefits, I see no reason to do so. In particular in combination with 
using gotos, the price being payed regarding maintainability is very 
high.
- Also things like ConditionalJumpShortcut in aoptx86.pas containing 
arm and aarch64 defines does not convince me regarding the patches.
- Patches contains open todo: "TODO: FIXME removing the first 
instruction fails"


I would really like to see parts of the patch applied, but this 
requires that it is re-arranged in small, oversee-able changes.

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


Re: [fpc-devel] Progress on reviewing x86_64 optimizer overhaul and node semantic pass

2019-10-26 Thread Florian Klämpfl

Am 18.10.19 um 18:07 schrieb J. Gareth Moreton:

Hi everyone,

How is everyone doing?  Sorry for my silence - been a bit tied up with 
things in life.  Anyway, that aside, has there been any further progress 
on reviewing the x86_64 optimizer overhaul over at 
https://bugs.freepascal.org/view.php?id=34628? I ask because I've 
sort-of blocked myself in any further improvements to the peephole 
optimizer.


I had meanwhile a look at it and to be honest, I am against applying the 
remainders in its current form.
- First, the patches are inter-winded and the single patches do not 
cover one single topic. Today, using e.g. TortoiseGit on Windows (sorry, 
on Linux there is no tool which comes close) such patches can be 
re-arranged without too much hazzle.
- Breaking the principle of the multiple optimizer passes is reasonable 
on the one hand, on the other hand it makes complicated code even more 
complicated and in particular as only the optimizer benefits, I see no 
reason to do so. In particular in combination with using gotos, the 
price being payed regarding maintainability is very high.
- Also things like ConditionalJumpShortcut in aoptx86.pas containing arm 
and aarch64 defines does not convince me regarding the patches.
- Patches contains open todo: "TODO: FIXME removing the first 
instruction fails"


I would really like to see parts of the patch applied, but this requires 
that it is re-arranged in small, oversee-able changes.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel