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
18 matches
Mail list logo
