Re: Unimpressed with pg_attribute_always_inline

2018-01-08 Thread Andres Freund
Hi, On 2018-01-08 20:20:09 -0500, Tom Lane wrote: > No, you have it right. I checked locally and confirmed Andres' assertion > that by default, gcc (my version anyway) is not persuaded to inline > ExecHashJoinImpl simply by "inline", but "always_inline" persuades it. > Maybe at some level higher

Re: Unimpressed with pg_attribute_always_inline

2018-01-08 Thread Tom Lane
Peter Geoghegan writes: > On Mon, Jan 8, 2018 at 5:09 PM, Peter Eisentraut > wrote: >> However, at it says, >> "GCC does not inline any functions when not optimizing unless you >> specify the ‘always_inline’ attribute for the function". So, >> app

Re: Unimpressed with pg_attribute_always_inline

2018-01-08 Thread Peter Geoghegan
On Mon, Jan 8, 2018 at 5:09 PM, Peter Eisentraut wrote: > However, at it says, > "GCC does not inline any functions when not optimizing unless you > specify the ‘always_inline’ attribute for the function". So, > apparently, if the goal is to turn o

Re: Unimpressed with pg_attribute_always_inline

2018-01-08 Thread Andres Freund
Hi, On 2018-01-08 20:09:27 -0500, Peter Eisentraut wrote: > On 1/8/18 19:56, Tom Lane wrote: > > Peter Geoghegan writes: > >> Anyway, ISTM that it should be possible to make > >> pg_attribute_always_inline have no effect in typical debug builds. > >> Wouldn't that make everyone happy? > > > > Th

Re: Unimpressed with pg_attribute_always_inline

2018-01-08 Thread Peter Eisentraut
On 1/8/18 19:56, Tom Lane wrote: > Peter Geoghegan writes: >> Anyway, ISTM that it should be possible to make >> pg_attribute_always_inline have no effect in typical debug builds. >> Wouldn't that make everyone happy? > > That would improve matters, but do we have access to the -O switch > level

Re: Unimpressed with pg_attribute_always_inline

2018-01-08 Thread Tom Lane
Peter Geoghegan writes: > Anyway, ISTM that it should be possible to make > pg_attribute_always_inline have no effect in typical debug builds. > Wouldn't that make everyone happy? That would improve matters, but do we have access to the -O switch level as an #if condition? The use-case I'm gener

Re: Unimpressed with pg_attribute_always_inline

2018-01-08 Thread Peter Geoghegan
On Mon, Jan 8, 2018 at 4:22 PM, Andres Freund wrote: >> Isn't that an argument against inlining in general, rather than >> forcing inlining in particular? > > No. Normal 'inline' annotation doesn't do anything on -O0 / debug > builds. But always_inline does, even though the goal of the usage is >

Re: Unimpressed with pg_attribute_always_inline

2018-01-08 Thread Andres Freund
On 2018-01-08 16:20:26 -0800, Peter Geoghegan wrote: > On Mon, Jan 8, 2018 at 4:12 PM, Tom Lane wrote: > > When I complained that always_inline inhibits debuggability, I did NOT > > mean what shows up in perf reports. I'm talking about whether you can > > break at, or single-step through, a funct

Re: Unimpressed with pg_attribute_always_inline

2018-01-08 Thread Peter Geoghegan
On Mon, Jan 8, 2018 at 4:12 PM, Tom Lane wrote: > When I complained that always_inline inhibits debuggability, I did NOT > mean what shows up in perf reports. I'm talking about whether you can > break at, or single-step through, a function reliably and whether gdb > knows where all the variables

Re: Unimpressed with pg_attribute_always_inline

2018-01-08 Thread Andres Freund
On 2018-01-08 19:12:08 -0500, Tom Lane wrote: > Andres Freund writes: > > Unless this pg_attribute_always_inline gets a lot more widely > > proliferated I don't see a need to change anything. Debuggability isn't > > meaningfully impacted by seing more runtime attributed to > > ExecHashJoin/ExecPar

Re: Unimpressed with pg_attribute_always_inline

2018-01-08 Thread Tom Lane
Andres Freund writes: > Unless this pg_attribute_always_inline gets a lot more widely > proliferated I don't see a need to change anything. Debuggability isn't > meaningfully impacted by seing more runtime attributed to > ExecHashJoin/ExecParallelHashJoin rather than ExecHashJoinImpl. When I comp

Re: Unimpressed with pg_attribute_always_inline

2018-01-08 Thread Andres Freund
On 2018-01-05 00:11:19 +1300, Thomas Munro wrote: > On Tue, Jan 2, 2018 at 4:58 PM, Thomas Munro > wrote: > > On Tue, Jan 2, 2018 at 4:17 PM, Tom Lane wrote: > >> gaur | nodeHashjoin.c:167: warning: `always_inline' attribute > >> directive ignored > >> mastodon | .\src\backend\executor\n

Re: Unimpressed with pg_attribute_always_inline

2018-01-04 Thread Thomas Munro
On Tue, Jan 2, 2018 at 4:58 PM, Thomas Munro wrote: > On Tue, Jan 2, 2018 at 4:17 PM, Tom Lane wrote: >> gaur | nodeHashjoin.c:167: warning: `always_inline' attribute >> directive ignored >> mastodon | .\src\backend\executor\nodeHashjoin.c(165): warning C4141: >> 'inline' : used more th

Re: Unimpressed with pg_attribute_always_inline

2018-01-01 Thread Thomas Munro
On Tue, Jan 2, 2018 at 4:17 PM, Tom Lane wrote: > baiji | .\src\backend\executor\nodeHashjoin.c(165): warning C4141: > 'inline' : used more than once > bowerbird | src/backend/executor/nodeHashjoin.c(165): warning C4141: > 'inline' : used more than once > [c:\prog\bf\root\HEAD\pgsql.build

Unimpressed with pg_attribute_always_inline

2018-01-01 Thread Tom Lane
I find myself entirely unimpressed with the results of commit dbb3d6f01. In the first place, even among the compilers that claim to understand that directive at all, there is a noticeable tendency to issue warnings. I find the following in recent buildfarm "make" logs: baiji | .\src\backend\