- Pharo-dev - lists.pharo.org

Debugging GCC code generation
by tesonep＠gmail.com Dec. 11, 2019

Dec. 11, 2019

Hi, this mail is related to Pharo because it is knowledge I found debugging the build of the VM, but the rest is to document it and perhaps someone will found it interesting (also I couldn't find it easily using Google). Sorry for the long mail! The problem ========== The following code does not produce good code in 8.3 when using optimizations: long __attribute__ ((noinline)) myFunc(long i, int index){ long v; long x = i >> 3; v = x; return ((int*)(&v))[index]; } #include <stdio.h> int main(){ long i; int x; scanf("%ld", &i); scanf("%d", &x); printf("%ld",myFunc(i,x)); } Basically, with -02, it generates the following code: myFunc: movslq %esi, %rsi movslq -8(%rsp,%rsi,4), %rax ret And with -01 it generates the following code: myFunc: sarq $3, %rdi movq %rdi, -8(%rsp) movslq %esi, %rsi movslq -8(%rsp,%rsi,4), %rax ret As you can see, the more optimized version is losing the bit shift (or any other operation). To detect the problem it was not easy, basically, I have used the Pharo Tests to detect the failing function and then to understand the generation of code in GCC, we need to debug its generation. The first snippet is generated using: gcc -O2 prb.c -S -o prb.s -Wall and the second using: gcc -O1 prb.c -S -o prb.s -Wall The GCC pipeline has different steps, I have centered my self in the tree optimizations. GCC dumps each of the intermediate states of the compilation, working with C like trees. For example to get the optimized version of the program, before generating the Assembler we have to do: gcc -O2 prb.c -S -o prb.s -Wall -fdump-tree-optimized=/dev/stdout This will generate: __attribute__((noinline)) myFunc (long int i, int index) { long int v; long unsigned int _1; long unsigned int _2; int * _3; int _4; long int _8; <bb 2> [local count: 1073741825]: _1 = (long unsigned int) index_7(D); _2 = _1 * 4; _3 = &v + _2; _4 = *_3; _8 = (long int) _4; v ={v} {CLOBBER}; return _8; } This is the optimized SSA (static single assign) version of the function (https://gcc.gnu.org/onlinedocs/gccint/SSA.html) As you can see in this version the code is already optimized, and our operations not correctly generated. We expect to see something like: __attribute__((noinline)) myFunc (long int i, int index) { long int x; long int v; long unsigned int _1; long unsigned int _2; int * _3; int _4; long int _10; <bb 2> [local count: 1073741825]: x_6 = i_5(D) >> 3; v = x_6; _1 = (long unsigned int) index_9(D); _2 = _1 * 4; _3 = &v + _2; _4 = *_3; _10 = (long int) _4; v ={v} {CLOBBER}; return _10; } In the first SSA version, we are lacking the shift operation: x_6 = i_5(D) >> 3; v = x_6; So, we need to see in which of the optimizations and transformations our code is lost: To see all the steps we should execute: gcc -O2 prb.c -S -o prb.s -Wall -fdump-tree-all This will generate a lot, really a lot, of files in the same directory. They have the name: prb.c.xxx.yyyy Where xxx is the number of the step, and yyyy is the name of the step. Each of the files contains the result of applying the changes, so what I have done is looking in binary search where my code was lost. I have found that the problem was in the first dead code elimination step (prb.c.041t.cddce1) GCC does not like the crap code that we are writing, as we are copying a stack variable and then accessing directly to the memory: v = x; return ((int*)(&v))[index]; So, basically, it was assuming that we were only using v and not x, so all the code modifying x is described (this optimization is called "dead store code deletion"). Basically tries to remove all the code that is affecting stack (temporary) variables that are never used. I am not sure if this is a bug in GCC, so I will report it. But I have fixed the problem writing the code in a proper way. Sorry again for the long mail, I wanted to store the knowledge and propagate it before I eventually will flush it. I like these things, but I am not debugging the GCC optimization pipeline all the days. -- Pablo Tesone. tesonep(a)gmail.com

5 11

[Pharo 8.0] Build #1065: Revert "[Perfs] x10 on method compiling with #deferFlushDuring:"
by ci-pharo-ci-jenkins2＠inria.fr Dec. 11, 2019

Dec. 11, 2019

There is a new Pharo build available! The status of the build #1065 was: SUCCESS. The Pull Request #5359 was integrated: "Revert "[Perfs] x10 on method compiling with #deferFlushDuring:"" Pull request url: https://github.com/pharo-project/pharo/pull/5359 Issue Url: https://github.com/pharo-project/pharo/issues/revert Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Willow Bootstrap & JQueryUI loading errors
by Sanjay Minni Dec. 11, 2019

Dec. 11, 2019

I get an error when trying to load Willow-bootstrap and willow-JQueryUI using the Metacello script (prior to this I have loaded Willow 12.1.0 first in Pharo 8 / Windows 10) maybe this has something to do with the following line in setUpDependencies: baseline: 'Willow' with: [ spec repository: 'github://ba-st/Willow:v12/source' ] if I pull in BaselineOfWillow-Bootstrap / JqueryUI thru iceberg, then edit Willow:v12 to Willow:12.1.0, then I can successfully load thru iceberg right-click metacello(default) except that it takes too long - seems it goes thru all the packages incl seaside etc each time can the Baseline(s) be fixed in the appropriate way and can the loading be optimised thanks Sanjay ----- cheers, Sanjay -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

2 2

code loading performance
by George Ganea Dec. 11, 2019

Dec. 11, 2019

Hi all, Currently loading GToolkit takes quite some time (arount 18 minutes at the best of times) we were wondering if thereâs been any attempts at improving code loading times in Metacello/Monticello. Or mabye there are some ideas on how one might start doing something like this? Cheers, George

5 7

[Pharo 8.0] Build #1064: [easyReview] examples in class comment for literalArrayNode
by ci-pharo-ci-jenkins2＠inria.fr Dec. 11, 2019

Dec. 11, 2019

There is a new Pharo build available! The status of the build #1064 was: SUCCESS. The Pull Request #5356 was integrated: "[easyReview] examples in class comment for literalArrayNode" Pull request url: https://github.com/pharo-project/pharo/pull/5356 Issue Url: https://github.com/pharo-project/pharo/issues/typo Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #1063: TextBackgroundColorAttribute
by ci-pharo-ci-jenkins2＠inria.fr Dec. 10, 2019

Dec. 10, 2019

There is a new Pharo build available! The status of the build #1063 was: SUCCESS. The Pull Request #5326 was integrated: "TextBackgroundColorAttribute" Pull request url: https://github.com/pharo-project/pharo/pull/5326 Issue Url: https://github.com/pharo-project/pharo/issues/TextBackgroundColorAttribute Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #1062: The access to all queries of the glyph cache should be synchronized
by ci-pharo-ci-jenkins2＠inria.fr Dec. 10, 2019

Dec. 10, 2019

There is a new Pharo build available! The status of the build #1062 was: SUCCESS. The Pull Request #5346 was integrated: "The access to all queries of the glyph cache should be synchronized" Pull request url: https://github.com/pharo-project/pharo/pull/5346 Issue Url: https://github.com/pharo-project/pharo/issues/5235 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #1061: BytecodeEncoderDeadCode
by ci-pharo-ci-jenkins2＠inria.fr Dec. 10, 2019

Dec. 10, 2019

There is a new Pharo build available! The status of the build #1061 was: SUCCESS. The Pull Request #5354 was integrated: "BytecodeEncoderDeadCode" Pull request url: https://github.com/pharo-project/pharo/pull/5354 Issue Url: https://github.com/pharo-project/pharo/issues/BytecodeEncoderDeadCode Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #1060: [Perfs] x10 on method compiling with #deferFlushDuring:
by ci-pharo-ci-jenkins2＠inria.fr Dec. 10, 2019

Dec. 10, 2019

There is a new Pharo build available! The status of the build #1060 was: SUCCESS. The Pull Request #5292 was integrated: "[Perfs] x10 on method compiling with #deferFlushDuring:" Pull request url: https://github.com/pharo-project/pharo/pull/5292 Issue Url: https://github.com/pharo-project/pharo/issues/betterHandleFileChangesDeferF… Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 8.0] Build #1059: 5349-showWarningOnTranscript-should-show-shadowed-vars-when-compiling
by ci-pharo-ci-jenkins2＠inria.fr Dec. 10, 2019

Dec. 10, 2019

There is a new Pharo build available! The status of the build #1059 was: SUCCESS. The Pull Request #5350 was integrated: "5349-showWarningOnTranscript-should-show-shadowed-vars-when-compiling" Pull request url: https://github.com/pharo-project/pharo/pull/5350 Issue Url: https://github.com/pharo-project/pharo/issues/5349 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0