search for: pes20

...me of the code This would more normally be done via target hooks in LLVM, though the principle is sound. > But it must be target-dependent as for example on Power a > seq_cst store has a fence before it, while on ARM it has a fence > both before and after it (per http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html) That certainly seems to suggest some kind of parametrisation. > For this exact reason, I am planning on splitting AtomicExpandLoadLinkedPass > in a target-independent and a target-dependent file: the current pass claims > to be target-independent but is actually d...

> Longer term, I hope to improve the fence elimination of the ARM backend with > a kind of PRE algorithm. Both of these improvements to the ARM backend > should be fairly straightforward to port to the POWER architecture later, > and I hope to also do that. > > Any reason these couldn't be done at the IR level? I definitely agree here. At the time, it was a plausible idea

...irs and only return a clobber result in such cases. My next steps will probably be to improve the compilation of acquire atomics in the ARM backend. In particular, they are currently compiled by a load + dmb, while a load + dependant useless branch + isb is also valid (see http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html for example) and may be faster. Even better: if there is already a dependant branch (such as the loop for the lowering of CAS), it is just a cheap isb. The main step will be switching off the InsertFencesForAtomic flag, and do the lowering of atomics in the backend, because o...

...is more likely that we are talking past each other. This stuff is subtle and although we have better ways of talking about it than (say) ten years ago, it is subtle. Two ways of talking about it are herd and ppcmem. The overview of ppcmem (AKA armmem and cppmem) is here: https://www.cl.cam.ac.uk/~pes20/ppcmem/help.html The intro to herd is here: http://arxiv.org/pdf/1308.6810v5.pdf It may be downloaded here: http://diy.inria.fr/herd/ As a very rough rule of thumb, herd is faster and easier to use and ppcmem is more precise. So SYNC_RMB is intended to implement smp_rmb(), correct? You could us...

...which is often more restrictive, or about obsolete or obscure hardware or compilers. We focussed on the behaviour of memory and pointers. We've had around 300 responses, including many compiler and OS developers, and the results are summarised below, or on the web at http://www.cl.cam.ac.uk/~pes20/cerberus (which also has more details). For many questions the outcome seems clear, but for some, especially 1, 2, 9, 10, and 11, major open questions about current compiler behaviour remain; we'd greatly appreciate informed comments on those from the relevant compiler developers (or other expe...

...ive, or about obsolete or obscure > hardware > or compilers. We focussed on the behaviour of memory and pointers. > > We've had around 300 responses, including many compiler and OS > developers, and the results are summarised below, or on the web at > http://www.cl.cam.ac.uk/~pes20/cerberus (which also has more > details). > For many questions the outcome seems clear, but for some, especially > 1, 2, 9, 10, and 11, major open questions about current compiler > behaviour remain; we'd greatly appreciate informed comments on those > from the relevant compiler...

On 01/14/2016 04:04 AM, Will Deacon wrote: > Consequently, it's important that the architecture back-ends implement > these portable primitives (e.g. smp_mb()) in a way that satisfies the > kernel memory model so that core code doesn't need to worry about the > underlying architecture for synchronisation purposes. It seems you don't listen me. I said multiple times -

On 01/14/2016 04:04 AM, Will Deacon wrote: > Consequently, it's important that the architecture back-ends implement > these portable primitives (e.g. smp_mb()) in a way that satisfies the > kernel memory model so that core code doesn't need to worry about the > underlying architecture for synchronisation purposes. It seems you don't listen me. I said multiple times -

...are > >> or compilers. We focussed on the behaviour of memory and pointers. > >> > >> We've had around 300 responses, including many compiler and OS > >> developers, and the results are summarised below, or on the web at > >> http://www.cl.cam.ac.uk/~pes20/cerberus (which also has more > >> details). > >> For many questions the outcome seems clear, but for some, especially > >> 1, 2, 9, 10, and 11, major open questions about current compiler > >> behaviour remain; we'd greatly appreciate informed comments on th...

...bsolete or obscure hardware >> or compilers. We focussed on the behaviour of memory and pointers. >> >> We've had around 300 responses, including many compiler and OS >> developers, and the results are summarised below, or on the web at >> http://www.cl.cam.ac.uk/~pes20/cerberus (which also has more details). >> For many questions the outcome seems clear, but for some, especially >> 1, 2, 9, 10, and 11, major open questions about current compiler >> behaviour remain; we'd greatly appreciate informed comments on those >> from the relevan...

On Wed, Jul 1, 2015 at 12:22 PM, Russell Wallace <russell.wallace at gmail.com> wrote: > I am arguing in favor of a point, and I understand you disagree with it, > but I don't think I'm dismissing any use cases except a very small > performance increment. > I'm sure Google has numbers about how much electricity/server cost they save for X% performance improvement.

Hi everyone, The OpenMP standards committee has begun work to formalize their memory model, and define its relationship to the C/C++ memory models. A questionnaire has been put together (pasted below), and I'd like everyone's help in composing detailed answers to inform their decision-making process. While our OpenMP support is still in active development, many of these questions apply

On 04/10/2017 09:55 AM, Andrey Bokhanko wrote: > Hi Hal, > > I wonder how your solution will handle the following? > > struct { > int s1_f1; > float s1_f2; > int s1_f3; > float s1_f4; > } S1; > > struct { > int s2_f1; > float s2_f2; > int *s2_f3; // to add some interest, suppose that sizeof(int) == > sizeof(int *) > float s2_f4;