Re: Where to place warning about non-optimized tail and sibling calls

2023-08-01 Thread Bradley Lucier via Gcc
On 8/1/23 6:08 PM, David Malcolm wrote: Or from libgccjit. FWIW I added it to support Scheme from libgccjit; see this patch kit: https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01287.html Perhaps there's a case for a frontend attribute for this. Dave Thanks. I thought a front-end warning mi

Re: Where to place warning about non-optimized tail and sibling calls

2023-08-01 Thread David Malcolm via Gcc
On Tue, 2023-08-01 at 20:20 +0200, Jose E. Marchesi via Gcc wrote: > > > > The Gambit Scheme->C compiler has an option to generate more > > > efficient > > > code if it knows that all tail and sibling calls in the generated > > > C > > > code will be optimized.  If gcc does not, however, optimize

Re: Where to place warning about non-optimized tail and sibling calls

2023-08-01 Thread Bradley Lucier via Gcc
On 8/1/23 12:51 PM, Paul Koning wrote: How is it possible to write valid C that is correct only if some optimization is done? Perhaps "incorrect" was the wrong word. If sibling-call optimization is not done, then perhaps the program will blow out the stack, which would not happen if the opt

Successful GCC source build to installation on GNU/Linux

2023-08-01 Thread Nevil
I sent this note after reading "Final install" and seeing the buildstat.html hasn't had 14.x yet, indicating my success in building and installing GCC. config.guess output: x86_64-pc-linux-gnu gcc -v output: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64

testdraft

2023-08-01 Thread Nevil
I sent this note after reading "Final install" and seeing the buildstat.html hasn't had 14.x yet, indicating my success in building and installing GCC. config.guess output: x86_64-pc-linux-gnu gcc -v output: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64

Re: Where to place warning about non-optimized tail and sibling calls

2023-08-01 Thread Jose E. Marchesi via Gcc
>> The Gambit Scheme->C compiler has an option to generate more efficient >> code if it knows that all tail and sibling calls in the generated C >> code will be optimized. If gcc does not, however, optimize a tail or >> sibling call, the generated C code may be incorrect (depending on >> circums

Re: Where to place warning about non-optimized tail and sibling calls

2023-08-01 Thread Jose E. Marchesi via Gcc
> The Gambit Scheme->C compiler has an option to generate more efficient > code if it knows that all tail and sibling calls in the generated C > code will be optimized. If gcc does not, however, optimize a tail or > sibling call, the generated C code may be incorrect (depending on > circumstance

Re: Update and Questions on CPython Extension Module -fanalyzer plugin development

2023-08-01 Thread David Malcolm via Gcc
On Tue, 2023-08-01 at 09:57 -0400, Eric Feng wrote: > > > > My guess is that you were trying to do it from the > > PLUGIN_ANALYZER_INIT > > hook rather than from the plugin_init function, but it's hard to be > > sure without seeing the code. > > > > Thanks Dave, you are entirely right — I made t

Re: Where to place warning about non-optimized tail and sibling calls

2023-08-01 Thread Paul Koning via Gcc
I'm puzzled. The fundamental rule of optimization is that it doesn't change the (defined) semantics of the program. How is it possible to write valid C that is correct only if some optimization is done? In other words, if it matters whether an optimization is done or not, that suggests to me

Where to place warning about non-optimized tail and sibling calls

2023-08-01 Thread Bradley Lucier via Gcc
The Gambit Scheme->C compiler has an option to generate more efficient code if it knows that all tail and sibling calls in the generated C code will be optimized. If gcc does not, however, optimize a tail or sibling call, the generated C code may be incorrect (depending on circumstances). So

Re: Update and Questions on CPython Extension Module -fanalyzer plugin development

2023-08-01 Thread Eric Feng via Gcc
> > My guess is that you were trying to do it from the PLUGIN_ANALYZER_INIT > hook rather than from the plugin_init function, but it's hard to be > sure without seeing the code. > Thanks Dave, you are entirely right — I made the mistake of trying to do it from PLUGIN_ANALYZER_INIT hook and not fro

Re: [Predicated Ins vs Branches] O3 and PGO result in 2x performance drop relative to O2

2023-08-01 Thread Changbin Du via Gcc
On Mon, Jul 31, 2023 at 08:55:35PM +0800, Changbin Du wrote: > The result (p-core, no ht, no turbo, performance mode): > > O2 O3 PGO > cycles 2,581,832,749 8,638,401,568 9,394,200,585 >

Re: [Predicated Ins vs Branches] O3 and PGO result in 2x performance drop relative to O2

2023-08-01 Thread Changbin Du via Gcc
On Tue, Aug 01, 2023 at 10:44:02AM +0200, Jan Hubicka wrote: > > > If I comment it out as above patch, then O3/PGO can get 16% and 12% > > > performance > > > improvement compared to O2 on x86. > > > > > > O2 O3 PGO > > > cycles 2,

Re: [Predicated Ins vs Branches] O3 and PGO result in 2x performance drop relative to O2

2023-08-01 Thread Changbin Du via Gcc
On Mon, Jul 31, 2023 at 03:53:26PM +0200, Richard Biener wrote: [snip] > > The main difference in the compilation output about code around the > > miss-prediction > > branch is: > > o In O2: predicated instruction (cmov here) is selected to eliminate above > > branch. cmov is true better tha

Re: [Predicated Ins vs Branches] O3 and PGO result in 2x performance drop relative to O2

2023-08-01 Thread Jan Hubicka via Gcc
> > If I comment it out as above patch, then O3/PGO can get 16% and 12% > > performance > > improvement compared to O2 on x86. > > > > O2 O3 PGO > > cycles 2,497,674,824 2,104,993,224 2,199,753,593 > > instructions1