On Thu, May 9, 2019 at 12:28 PM Steven Rostedt wrote:
>
> But it probably would probably still be good to know why this fixes the
> issues you see.
Looks like a compiler bug, plain and simple.
The simplified case really simplifies a lot for the internal IR, and
has a single conditional that then
On Thu, 9 May 2019 15:06:44 -0400
Steven Rostedt wrote:
> Hmm, I'm still working on my pull request for the merge window, and if
> this already went in, I could just add this, and let it conflict. I'm
> sure Linus will have no problems in fixing up the conflicts.
>
> I should change the subject,
On Thu, 9 May 2019 13:45:31 -0500
Josh Poimboeuf wrote:
> Actually, my original fix already went in:
>
> 37686b1353cf ("tracing: Improve "if" macro code generation")
>
> But it introduced a regression:
>
> https://lkml.kernel.org/r/201905040509.iqq2crou%...@intel.com
>
> which Linus' patc
On 5/9/19 11:47 AM, Josh Poimboeuf wrote:
> On Thu, May 09, 2019 at 01:45:31PM -0500, Josh Poimboeuf wrote:
>> On Thu, May 09, 2019 at 02:29:02PM -0400, Steven Rostedt wrote:
>>> On Thu, 9 May 2019 09:51:59 -0700
>>> Linus Torvalds wrote:
>>>
On Thu, May 9, 2019 at 6:01 AM Steven Rostedt wro
On Thu, May 09, 2019 at 01:45:31PM -0500, Josh Poimboeuf wrote:
> On Thu, May 09, 2019 at 02:29:02PM -0400, Steven Rostedt wrote:
> > On Thu, 9 May 2019 09:51:59 -0700
> > Linus Torvalds wrote:
> >
> > > On Thu, May 9, 2019 at 6:01 AM Steven Rostedt wrote:
> > > >
> > > > This patch works. Can I
On Thu, May 09, 2019 at 11:48:43AM -0700, Randy Dunlap wrote:
> On 5/9/19 11:47 AM, Josh Poimboeuf wrote:
> > On Thu, May 09, 2019 at 01:45:31PM -0500, Josh Poimboeuf wrote:
> >> On Thu, May 09, 2019 at 02:29:02PM -0400, Steven Rostedt wrote:
> >>> On Thu, 9 May 2019 09:51:59 -0700
> >>> Linus Torv
On Thu, May 09, 2019 at 02:29:02PM -0400, Steven Rostedt wrote:
> On Thu, 9 May 2019 09:51:59 -0700
> Linus Torvalds wrote:
>
> > On Thu, May 9, 2019 at 6:01 AM Steven Rostedt wrote:
> > >
> > > This patch works. Can I get your Signed-off-by for it?
> >
> > Yes. Please write some kind of comp
On Thu, 9 May 2019 09:51:59 -0700
Linus Torvalds wrote:
> On Thu, May 9, 2019 at 6:01 AM Steven Rostedt wrote:
> >
> > This patch works. Can I get your Signed-off-by for it?
>
> Yes. Please write some kind of comprehensible commit log for it, but
How's this:
"Peter Zijlstra noticed that wit
On Thu, May 9, 2019 at 6:01 AM Steven Rostedt wrote:
>
> This patch works. Can I get your Signed-off-by for it?
Yes. Please write some kind of comprehensible commit log for it, but
Signed-off-by: Linus Torvalds
for the patch itself.
Linus
On Wed, 20 Mar 2019 10:26:17 -0700
Linus Torvalds wrote:
> On Wed, Mar 20, 2019 at 4:17 AM David Laight wrote:
> >
> > > __r = !!(cond); \
> >
> > Is that (or maybe just the !!) needed any more??
>
> It is, because the 'cond' e
On Wed, 20 Mar 2019 10:26:17 -0700
Linus Torvalds wrote:
> - Steven has this crazy model of "more underscores are better". They
> aren't. They don't help if things nest anyway, but what does help is
> meaningful names. Both when things don't nest, and when looking at
> generated asm files.
Not
On Wed, Mar 20, 2019 at 10:36 AM David Laight wrote:
>
>
> Actually you can avoid double evaluation by doing:
>
> (cond) ? (__f.miss_hit[1]++, 1) : (__f.miss_hit[0]++,
> 0)
I don't think you looked at the patch in my attachment of the email
you replied to, did you?
That'
From: Linus Torvalds
> Sent: 20 March 2019 17:26
> To: David Laight
> On Wed, Mar 20, 2019 at 4:17 AM David Laight wrote:
> >
> > > __r = !!(cond); \
> >
> > Is that (or maybe just the !!) needed any more??
>
> It is, because the 'con
On Wed, Mar 20, 2019 at 4:17 AM David Laight wrote:
>
> > __r = !!(cond); \
>
> Is that (or maybe just the !!) needed any more??
It is, because the 'cond' expression might not be an int, it could be
a test for a pointer being non-NULL,
From: > Peter Zijlstra
> Sent: 18 March 2019 15:39
>
> With CONFIG_PROFILE_ALL_BRANCHES, the "if" macro converts the
> conditional to an array index. This can cause GCC to create horrible
> code. When there are nested ifs, the generated code uses register
> values to encode branching decisions.
On Mon, Mar 18, 2019 at 06:37:20PM -0500, Josh Poimboeuf wrote:
> On Mon, Mar 18, 2019 at 04:38:42PM +0100, Peter Zijlstra wrote:
> > With CONFIG_PROFILE_ALL_BRANCHES, the "if" macro converts the
> > conditional to an array index. This can cause GCC to create horrible
> > code. When there are nes
On Mon, Mar 18, 2019 at 04:38:42PM +0100, Peter Zijlstra wrote:
> With CONFIG_PROFILE_ALL_BRANCHES, the "if" macro converts the
> conditional to an array index. This can cause GCC to create horrible
> code. When there are nested ifs, the generated code uses register
> values to encode branching d
On Mon, 18 Mar 2019 16:38:42 +0100
Peter Zijlstra wrote:
> With CONFIG_PROFILE_ALL_BRANCHES, the "if" macro converts the
> conditional to an array index. This can cause GCC to create horrible
> code. When there are nested ifs, the generated code uses register
> values to encode branching decisi
With CONFIG_PROFILE_ALL_BRANCHES, the "if" macro converts the
conditional to an array index. This can cause GCC to create horrible
code. When there are nested ifs, the generated code uses register
values to encode branching decisions.
Make it easier for GCC to optimize by keeping the conditional
19 matches
Mail list logo
