> On July 13, 2015 at 11:06 PM Denys Vlasenko
> wrote:
>
> Not *your* way.
> I meant that I'll send patches to Ingo - I see that he agrees that
> this worth fixing instead of waiting for a better compiler.
Yeah, do it. Sorry it was not my intention to prevent you to fix this -
not at all. Go on,
On Mon, Jul 13, 2015 at 9:20 PM, Hagen Paul Pfeifer wrote:
>> On July 13, 2015 at 8:27 PM Denys Vlasenko
>> wrote:
>
>> > So I think the original patch makes sense (and I already applied it),
>> > we want known-simple and performance critical methods (such as atomic
>> > ops) always inlined.
>>
>
> On July 13, 2015 at 8:27 PM Denys Vlasenko
> wrote:
> > So I think the original patch makes sense (and I already applied it),
> > we want known-simple and performance critical methods (such as atomic
> > ops) always inlined.
>
> I will send more such force-inlining patches your way then.
Now?
On Wed, Apr 22, 2015 at 11:28 AM, Ingo Molnar wrote:
> So I think the original patch makes sense (and I already applied it),
> we want known-simple and performance critical methods (such as atomic
> ops) always inlined.
I will send more such force-inlining patches your way then.
--
To unsubscribe
On Wed, Apr 22, 2015 at 11:20 AM, Markus Trippelsdorf
wrote:
> On 2015.04.22 at 07:58 +0200, Hagen Paul Pfeifer wrote:
>> * Markus Trippelsdorf | 2015-04-22 07:24:41 [+0200]:
>> >I cannot reproduce this issue with my config with 4.8, 4.9 or 5. Could
>> >you please come up with a small testcase and
On Wed, 22 Apr 2015, Hagen Paul Pfeifer wrote:
> On 22 April 2015 at 11:28, Ingo Molnar wrote:
> > So I think the original patch makes sense (and I already applied it),
> > we want known-simple and performance critical methods (such as atomic
> > ops) always inlined.
>
> Right. As I wrote I will
On 22 April 2015 at 11:28, Ingo Molnar wrote:
> So I think the original patch makes sense (and I already applied it),
> we want known-simple and performance critical methods (such as atomic
> ops) always inlined.
Right. As I wrote I will post a follow up patch for the remaining
cases where inlin
* Markus Trippelsdorf wrote:
> On 2015.04.22 at 07:58 +0200, Hagen Paul Pfeifer wrote:
> > * Markus Trippelsdorf | 2015-04-22 07:24:41 [+0200]:
> > >I cannot reproduce this issue with my config with 4.8, 4.9 or 5. Could
> > >you please come up with a small testcase and open a gcc bug (with full
On 2015.04.22 at 07:58 +0200, Hagen Paul Pfeifer wrote:
> * Markus Trippelsdorf | 2015-04-22 07:24:41 [+0200]:
> >I cannot reproduce this issue with my config with 4.8, 4.9 or 5. Could
> >you please come up with a small testcase and open a gcc bug (with full
> >gcc command line)?
>
> the attached
On 2015.04.22 at 00:57 +0200, Hagen Paul Pfeifer wrote:
> We see ordinary "template" reuse of common driver code without renaming the
> copied static's. But compiled with CONFIG_OPTIMIZE_INLINING=y the inlining is
> not respected by gcc:
>
> atomic_inc: 544 duplicates
>rcu_read
On Tue, Apr 21, 2015 at 3:57 PM, Hagen Paul Pfeifer wrote:
>
> Is it possible that gcc is bedeviled because of inline assembler
> parts which brings confuse the internal scoring system?
yes, I have this memory of having seen that before - the size
heuristics for gcc getting confused by inlining.
* Ingo Molnar | 2015-04-21 09:42:12 [+0200]:
Hey Ingo,
>So the thing is that allyesconfig turns on -Os:
>
> CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_CC_OPTIMIZE_FOR_SIZE seems to have no effect, The only option which
makes a difference is CONFIG_OPTIMIZE_INLINING! But this is not a big surprise:
*
On 21 April 2015 at 09:42, Ingo Molnar wrote:
Hey Ingo, Peter, Boris,
the environment is Debian with gcc version 4.9.2. I tried to reproduce
the results under Ubuntu 14.04 but their version (4.8.2!) seems fine:
at max one duplicate for each atomic_* function.
> So the thing is that allyesconfig
* Hagen Paul Pfeifer wrote:
> On 20 April 2015 at 23:56, Borislav Petkov wrote:
>
> > Hmm, that must be config-specific as doing
> >
> > objdump -D vmlinux | grep -i "atomic_add"
> >
> > here gives me only "drm_atomic_add_affected_connectors" matches.
> >
> > It probably gets inlined here alwa
On Mon, Apr 20, 2015 at 11:27:11PM +0200, Hagen Paul Pfeifer wrote:
> During some code analysis I realized that atomic_add, atomic_sub and
> friends are not necessarily inlined AND that each function is defined
> multiple times:
>
> atomic_inc: 544 duplicates
> atomic_dec: 215 du
On 20 April 2015 at 23:56, Borislav Petkov wrote:
> Hmm, that must be config-specific as doing
>
> objdump -D vmlinux | grep -i "atomic_add"
>
> here gives me only "drm_atomic_add_affected_connectors" matches.
>
> It probably gets inlined here always...
Probably, the config is allyesconfig minus
On Mon, Apr 20, 2015 at 11:27:11PM +0200, Hagen Paul Pfeifer wrote:
> During some code analysis I realized that atomic_add, atomic_sub and
> friends are not necessarily inlined AND that each function is defined
> multiple times:
>
> atomic_inc: 544 duplicates
> atomic_dec: 215 du
During some code analysis I realized that atomic_add, atomic_sub and
friends are not necessarily inlined AND that each function is defined
multiple times:
atomic_inc: 544 duplicates
atomic_dec: 215 duplicates
atomic_dec_and_test: 107 duplicates
atomic64_inc: 38 duplicates
18 matches
Mail list logo
