On Fri, Apr 09, 2021 at 12:33:29PM -0700, Nick Desaulniers wrote:
> Since asm goto is implicitly volatile qualified, it sounds like
> removing the implicit volatile qualifier from asm goto might help?
> Then if there were side effects but you forgot to inform the compiler
> that there were via an
From: David Malcolm
> Sent: 09 April 2021 14:49
...
> With the caveat that my knowledge of GCC's middle-end is mostly about
> implementing warnings, rather than optimization, I did some
> experimentation, with gcc trunk on x86_64 FWIW.
>
> Given:
>
> int __attribute__((pure)) foo(void);
>
> int
On Fri, Apr 09, 2021 at 05:07:15PM -0400, David Malcolm wrote:
> You've built a very specific thing out of asm-goto to fulfil the tough
> requirements you outlined above - as well as the nops, there's a thing
> in another section to contend with.
>
> How to merge these asm-goto constructs?
By
On Fri, 2021-04-09 at 22:09 +0200, Peter Zijlstra wrote:
> On Fri, Apr 09, 2021 at 03:21:49PM -0400, David Malcolm wrote:
> > [Caveat: I'm a gcc developer, not a kernel expert]
> >
> > But it's not *quite* a global constant, or presumably you would be
> > simply using a global constant, right?
On Fri, Apr 09, 2021 at 12:33:29PM -0700, Nick Desaulniers wrote:
> On Fri, Apr 9, 2021 at 4:18 AM Peter Zijlstra wrote:
> >
> > On Fri, Apr 09, 2021 at 12:55:18PM +0200, Florian Weimer wrote:
> > > * Ard Biesheuvel:
> > >
> > > > Wouldn't that require the compiler to interpret the contents of
On Fri, Apr 09, 2021 at 03:21:49PM -0400, David Malcolm wrote:
> [Caveat: I'm a gcc developer, not a kernel expert]
>
> But it's not *quite* a global constant, or presumably you would be
> simply using a global constant, right? As the optimizer gets smarter,
> you don't want to have it one day
On Fri, Apr 9, 2021 at 4:18 AM Peter Zijlstra wrote:
>
> On Fri, Apr 09, 2021 at 12:55:18PM +0200, Florian Weimer wrote:
> > * Ard Biesheuvel:
> >
> > > Wouldn't that require the compiler to interpret the contents of the
> > > asm() block?
> >
> > Yes and no. It would require proper toolchain
On Fri, 2021-04-09 at 20:40 +0200, Peter Zijlstra wrote:
> On Fri, Apr 09, 2021 at 09:48:33AM -0400, David Malcolm wrote:
> > You tried __pure on arch_static_branch; did you try it on
> > static_branch_unlikely?
>
> static_branch_unlikely() is a CPP macro that expands to a statement
> expression,
On Fri, Apr 09, 2021 at 09:48:33AM -0400, David Malcolm wrote:
> You tried __pure on arch_static_branch; did you try it on
> static_branch_unlikely?
static_branch_unlikely() is a CPP macro that expands to a statement
expression, or as with the later patch, a _Generic(). I'm not sure how
to apply
On Fri, 2021-04-09 at 15:13 +0200, Peter Zijlstra wrote:
> On Fri, Apr 09, 2021 at 03:01:50PM +0200, Peter Zijlstra wrote:
> > On Fri, Apr 09, 2021 at 02:03:46PM +0200, Peter Zijlstra wrote:
> > > On Fri, Apr 09, 2021 at 07:55:42AM -0400, David Malcolm wrote:
> >
> > > > Sorry if this is a dumb
On Fri, Apr 09, 2021 at 03:01:50PM +0200, Peter Zijlstra wrote:
> On Fri, Apr 09, 2021 at 02:03:46PM +0200, Peter Zijlstra wrote:
> > On Fri, Apr 09, 2021 at 07:55:42AM -0400, David Malcolm wrote:
>
> > > Sorry if this is a dumb question, but does the function attribute:
> > > __attribute__
On Thu, Apr 08, 2021 at 06:52:18PM +0200, Peter Zijlstra wrote:
> Is there *any* way in which we can have the compiler recognise that the
> asm_goto only depends on its arguments and have it merge the branches
> itself?
>
> I do realize that asm-goto being volatile this is a fairly huge ask, but
On Fri, Apr 09, 2021 at 02:03:46PM +0200, Peter Zijlstra wrote:
> On Fri, Apr 09, 2021 at 07:55:42AM -0400, David Malcolm wrote:
> > Sorry if this is a dumb question, but does the function attribute:
> > __attribute__ ((pure))
> > help here? It's meant to allow multiple calls to a predicate
On Fri, Apr 09, 2021 at 07:55:42AM -0400, David Malcolm wrote:
> On Fri, 2021-04-09 at 13:12 +0200, Peter Zijlstra wrote:
> > On Fri, Apr 09, 2021 at 11:57:22AM +0200, Ard Biesheuvel wrote:
> > > On Thu, 8 Apr 2021 at 18:53, Peter Zijlstra
> > > wrote:
> >
> > > > Is there *any* way in which we
On Fri, 2021-04-09 at 13:12 +0200, Peter Zijlstra wrote:
> On Fri, Apr 09, 2021 at 11:57:22AM +0200, Ard Biesheuvel wrote:
> > On Thu, 8 Apr 2021 at 18:53, Peter Zijlstra
> > wrote:
>
> > > Is there *any* way in which we can have the compiler recognise
> > > that the
> > > asm_goto only depends
On Fri, Apr 09, 2021 at 12:55:18PM +0200, Florian Weimer wrote:
> * Ard Biesheuvel:
>
> > Wouldn't that require the compiler to interpret the contents of the
> > asm() block?
>
> Yes and no. It would require proper toolchain support, so in this case
> a new ELF relocation type, with compiler,
On Fri, Apr 09, 2021 at 11:57:22AM +0200, Ard Biesheuvel wrote:
> On Thu, 8 Apr 2021 at 18:53, Peter Zijlstra wrote:
> > Is there *any* way in which we can have the compiler recognise that the
> > asm_goto only depends on its arguments and have it merge the branches
> > itself?
> >
> > I do
* Ard Biesheuvel:
> Wouldn't that require the compiler to interpret the contents of the
> asm() block?
Yes and no. It would require proper toolchain support, so in this case
a new ELF relocation type, with compiler, assembler, and linker support
to generate those relocations and process them.
On Thu, 8 Apr 2021 at 18:53, Peter Zijlstra wrote:
>
> Hi!
>
> Given code like:
>
> DEFINE_STATIC_KEY_FALSE(sched_schedstats);
>
> #define schedstat_enabled()
> static_branch_unlikely(_schedstats)
> #define schedstat_set(var, val) do { if (schedstat_enabled()) { var =
>
Hi!
Given code like:
DEFINE_STATIC_KEY_FALSE(sched_schedstats);
#define schedstat_enabled()
static_branch_unlikely(_schedstats)
#define schedstat_set(var, val) do { if (schedstat_enabled()) { var =
(val); } } while (0)
#define __schedstat_set(var, val) do { var =
20 matches
Mail list logo
