On Mon, Aug 05, 2013 at 12:55:15PM -0400, Steven Rostedt wrote:
[ sent to both Linux kernel mailing list and to gcc list ]
Let me hijack this thread for something related...
I've been wanting to 'abuse' static_key/asm-goto to sort-of JIT
if-forest functions like perf_prepare_sample() and
On Mon, Aug 12, 2013 at 07:56:10AM -0700, H. Peter Anvin wrote:
On 08/12/2013 02:17 AM, Peter Zijlstra wrote:
I've been wanting to 'abuse' static_key/asm-goto to sort-of JIT
if-forest functions like perf_prepare_sample() and perf_output_sample().
They are of the form:
void func
On Mon, Aug 12, 2013 at 10:47:37AM -0700, H. Peter Anvin wrote:
On 08/12/2013 09:09 AM, Peter Zijlstra wrote:
On the majority of architectures, including x86, you cannot simply copy
a piece of code elsewhere and have it still work.
I thought we used -fPIC which would allow just
On Thu, Feb 06, 2014 at 08:20:51PM -0800, Paul E. McKenney wrote:
Hopefully some discussion of out-of-thin-air values as well.
Yes, absolutely shoot store speculation in the head already. Then drive
a wooden stake through its hart.
C11/C++11 should not be allowed to claim itself a memory model
On Fri, Feb 07, 2014 at 05:13:36PM +, Will Deacon wrote:
Understood, but that doesn't explain why Paul wants to add ISB/isync
instructions which affect the *CPU* rather than the compiler!
I doubt Paul wants it, but yeah, I'm curious about that proposal as
well, sounds like someone took a
On Fri, Feb 07, 2014 at 04:55:48PM +, Will Deacon wrote:
Hi Paul,
On Fri, Feb 07, 2014 at 04:50:28PM +, Paul E. McKenney wrote:
On Fri, Feb 07, 2014 at 08:44:05AM +0100, Peter Zijlstra wrote:
On Thu, Feb 06, 2014 at 08:20:51PM -0800, Paul E. McKenney wrote:
Hopefully some
On Mon, Feb 10, 2014 at 01:27:51AM +0100, Torvald Riegel wrote:
Initial state: x == y == 0
T1: r1 = atomic_load_explicit(x, memory_order_relaxed);
atomic_store_explicit(42, y, memory_order_relaxed);
if (r1 != 42)
atomic_store_explicit(r1, y, memory_order_relaxed);
On Fri, Feb 07, 2014 at 10:02:16AM -0800, Paul E. McKenney wrote:
As near as I can tell, compiler writers hate the idea of prohibiting
speculative-store optimizations because it requires them to introduce
both control and data dependency tracking into their compilers. Many of
them seem to
On Mon, Feb 10, 2014 at 11:49:29AM +, Will Deacon wrote:
On Mon, Feb 10, 2014 at 11:48:13AM +, Peter Zijlstra wrote:
On Fri, Feb 07, 2014 at 10:02:16AM -0800, Paul E. McKenney wrote:
As near as I can tell, compiler writers hate the idea of prohibiting
speculative-store
I don't know the specifics of your example, but from how I understand
it, I don't see a problem if the compiler can prove that the store will
always happen.
To be more specific, if the compiler can prove that the store will
happen anyway, and the region of code can be assumed to always run
On Wed, Feb 12, 2014 at 09:42:09AM -0800, Paul E. McKenney wrote:
You need volatile semantics to force the compiler to ignore any proofs
it might otherwise attempt to construct. Hence all the ACCESS_ONCE()
calls in my email to Torvald. (Hopefully I translated your example
reasonably.)
My
On Thu, Feb 13, 2014 at 09:07:55PM -0800, Torvald Riegel wrote:
That depends on what your goal is.
A compiler that we don't need to fight in order to generate sane code
would be nice. But as Linus said; we can continue to ignore you lot and
go on as we've done.
On Tue, Feb 18, 2014 at 12:12:06PM +, Peter Sewell wrote:
Several of you have said that the standard and compiler should not
permit speculative writes of atomics, or (effectively) that the
compiler should preserve dependencies.
The example below only deals with control dependencies; so
On Tue, Feb 18, 2014 at 10:21:56PM +0100, Torvald Riegel wrote:
Yes, I do. But that seems to be volatile territory. It crosses the
boundaries of the abstract machine, and thus is input/output. Which
fraction of your atomic accesses can read values produced by hardware?
I would still suppose
4. Some drivers allow user-mode code to mmap() some of their
state. Any changes undertaken by the user-mode code would
be invisible to the compiler.
A good point, but a compiler that doesn't try to (incorrectly) assume
something about the semantics of mmap will simply see that
On Wed, Feb 19, 2014 at 12:07:02PM +0100, Torvald Riegel wrote:
Its not only hardware; also the kernel/user boundary has this same
problem. We cannot a-priory say what userspace will do; in fact, because
we're a general purpose OS, we must assume it will willfully try its
bestest to wreck
On Tue, Jun 10, 2014 at 03:23:36PM +0200, Jiri Kosina wrote:
+# Tell gcc to never replace conditional load with a non-conditional one
+KBUILD_CFLAGS+= $(call cc-option,--param allow-store-data-races=0)
+
Why do we not want: -fmemory-model=safe? And should we not at the very
least also
On Tue, Jun 10, 2014 at 05:04:55PM +0200, Marek Polacek wrote:
On Tue, Jun 10, 2014 at 04:53:27PM +0200, Peter Zijlstra wrote:
On Tue, Jun 10, 2014 at 03:23:36PM +0200, Jiri Kosina wrote:
+# Tell gcc to never replace conditional load with a non-conditional one
+KBUILD_CFLAGS+= $(call
On Wed, 2009-11-25 at 20:38 +0100, Richard Guenther wrote:
If you can offer advice on how to teach quilt
(which I belive uses patch) to ignore whitespace changes when
applying patches then more power to you
QUILT_PATCH_OPTS=-l
of with
this issue :-(, google gives a lot of hits on the issue but it is a bit
hard to get the current impl. status for 3.4. Which in turn makes it
hard to decide on how to bandage our foot.
Kind regards,
Peter Zijlstra
On Mon, 2005-08-15 at 06:12 -0700, Dan Kegel wrote:
Peter Zijlstra [EMAIL PROTECTED] wrote:
On this controversial subject, could somebody please - pretty please
with a cherry on top - tell me what the current status is:
- in general,
- as implemented in the 3.4 series
On Mon, 2005-08-15 at 09:33 -0400, Andrew Pinski wrote:
Peter Zijlstra [EMAIL PROTECTED] wrote:
On this controversial subject, could somebody please - pretty please
with a cherry on top - tell me what the current status is:
- in general,
- as implemented in the 3.4 series
are
not an option.
Nor do I think they (being the company I work for) will allow me to ship
patched versions of libpthread.so and libstdc++.so.5.
Too bad, guess I have to redesign the issue.
Peter Zijlstra
exception model
make[1]: *** [configure-target-libstdc++-v3] Error 1
make[1]: Leaving directory `/usr/local/src/gcc-4.0-20051117/build'
make: *** [bootstrap] Error 2
I'm sure I'm doing something horribly wrong here, can somebody point me
to the way of a working compiler?
Kind regards,
Peter
On Tue, Apr 28, 2020 at 02:41:33PM +0100, Andrew Cooper wrote:
> Its fine to focus on userspace first, but the kernel is far more simple.
>
> Looking at that presentation, the only thing missing for kernel is the
> notrack thunks, in the unlikely case that such code would be tolerated
> (Frankly,
On Mon, Nov 09, 2020 at 11:50:15AM -0800, Nick Desaulniers wrote:
> On Mon, Nov 9, 2020 at 11:46 AM Segher Boessenkool
> wrote:
> >
> > On Mon, Nov 09, 2020 at 01:47:13PM +0100, Peter Zijlstra wrote:
> > >
> > > + lots of people and linux-toolchains
> >
On Mon, Nov 09, 2020 at 01:38:51PM -0600, Segher Boessenkool wrote:
> On Mon, Nov 09, 2020 at 01:47:13PM +0100, Peter Zijlstra wrote:
> >
> > + lots of people and linux-toolchains
> >
> > On Wed, Nov 04, 2020 at 07:31:42PM +0100, Uros Bizjak wrote:
> > &g
On Tue, Nov 10, 2020 at 10:42:58AM -0800, Nick Desaulniers wrote:
> When I think of qualifiers, I think of const and volatile. I'm not
> sure why the first post I'm cc'ed on talks about "segment" qualifiers.
> Maybe it's in reference to a variable attribute that the kernel
> defines? Looking at
On Mon, Nov 16, 2020 at 12:23:17PM +, Uecker, Martin wrote:
> > > > Another way to drop qualifiers is using a cast. So you
> > > > can use typeof twice:
> > > >
> > > > typeof((typeof(_var))_var) tmp__;
> > > >
> > > > This also works for non-scalars but this is a GCC extension.
>
> (That
proposed above seems
very error prone to me.
---
Subject: compiler: Improve __unqual_typeof()
Improve our __unqual_scalar_typeof() implementation by relying on C
dropping qualifiers for lvalue convesions. There is one small catch in
that GCC is currently known broken in this respect, however it happens
On Mon, Nov 16, 2020 at 12:10:56PM +0100, Peter Zijlstra wrote:
> > > Another way to drop qualifiers is using a cast. So you
> > > can use typeof twice:
> > >
> > > typeof((typeof(_var))_var) tmp__;
> > >
> > > This also works for non-s
+ lots of people and linux-toolchains
On Wed, Nov 04, 2020 at 07:31:42PM +0100, Uros Bizjak wrote:
> Hello!
>
> I was looking at the recent linux patch series [1] where segment
> qualifiers (named address spaces) were introduced to handle percpu
> variables. In the patch [2], the author
On Tue, Apr 05, 2022 at 01:51:30PM +0100, Mark Rutland wrote:
> Hi all,
>
> [adding kernel folk who work on asm stuff]
>
> As a heads-up, GCC 12 (not yet released) appears to erroneously optimize away
> calls to functions with volatile asm. Szabolcs has raised an issue on the GCC
> bugzilla:
>
On Fri, Jul 07, 2023 at 10:04:06AM -0400, Olivier Dion wrote:
> On Tue, 04 Jul 2023, Peter Zijlstra wrote:
> > On Mon, Jul 03, 2023 at 03:20:31PM -0400, Olivier Dion wrote:
> [...]
> >> On x86-64 (gcc 13.1 -O2) we get:
> >>
> >> t0():
> >>
On Mon, Jul 03, 2023 at 03:20:31PM -0400, Olivier Dion wrote:
> int x = 0;
> int y = 0;
> int r0, r1;
>
> int dummy;
>
> void t0(void)
> {
> __atomic_store_n(, 1, __ATOMIC_RELAXED);
>
> __atomic_exchange_n(, 1, __ATOMIC_SEQ_CST);
>
On Mon, Nov 15, 2021 at 12:33:16PM +0530, Prathamesh Kulkarni wrote:
> On Sun, 14 Nov 2021 at 02:07, David Malcolm via Gcc-patches
> > +/* Handle "returns_zero_on_failure" and "returns_zero_on_success"
> > attributes;
> > + arguments as in struct attribute_spec.handler. */
> > +
> > +static
On Sat, Nov 13, 2021 at 03:37:24PM -0500, David Malcolm wrote:
> This approach is much less expressive that the custom addres space
> approach; it would only cover the trust boundary aspect; it wouldn't
> cover any differences between generic pointers and __user, vs __iomem,
> __percpu, and __rcu
On Sat, Mar 25, 2023 at 01:54:16AM -0700, Dan Li wrote:
> In the compiler part[4], most of the content is the same as Sami's
> implementation[3], except for some minor differences, mainly including:
>
> 1. The function typeid is calculated differently and it is difficult
> to be consistent.
38 matches
Mail list logo
