search for: strengthens

Has anyone done any experiments with regards to type strengthening or weakening in the context of LLVM? For example, the GWT compiler does type strengthening - that is, if you are calling a method on an interface or abstract type, and the compiler determines through live variable analysis what the concrete type is, then it goes ahead and re-writes the type information to be the stronger

Talin wrote: > For example, the GWT compiler does type strengthening - that is, if you > are calling a method on an interface or abstract type, and the compiler > determines through live variable analysis what the concrete type is, > then it goes ahead and re-writes the type information to be the stronger > type. The advantage is that it may then be able to do additional >

On Tue, Jun 30, 2020 at 09:47:30PM +0200, Marco Elver wrote: > I do wonder, though, if there is some way to make the compiler do > something better for us. Clearly, implementing real > memory_order_consume hasn't worked out until today. But maybe the > compiler could promote dependent loads to acquires if it recognizes it > lost dependencies during optimizations. Just thinking

On Tue, Jun 30, 2020 at 09:47:30PM +0200, Marco Elver wrote: > On Tue, 30 Jun 2020 at 19:39, Will Deacon <will at kernel.org> wrote: > > > > When building with LTO, there is an increased risk of the compiler > > converting an address dependency headed by a READ_ONCE() invocation > > into a control dependency and consequently allowing for harmful > >

On Tue, Jun 30, 2020 at 03:57:54PM -0700, Sami Tolvanen wrote: > On Tue, Jun 30, 2020 at 12:47 PM Marco Elver <elver at google.com> wrote: > > > > On Tue, 30 Jun 2020 at 19:39, Will Deacon <will at kernel.org> wrote: > > > > > > When building with LTO, there is an increased risk of the compiler > > > converting an address dependency headed by a

On Tue, Jun 30, 2020 at 09:25:03PM +0200, Arnd Bergmann wrote: > On Tue, Jun 30, 2020 at 7:39 PM Will Deacon <will at kernel.org> wrote: > > +#define __READ_ONCE(x) \ > > +({ \ > > + int atomic = 1; \

On Mon, Jul 06, 2020 at 05:08:20PM +0100, Dave Martin wrote: > On Tue, Jun 30, 2020 at 06:37:34PM +0100, Will Deacon wrote: > > diff --git a/arch/arm64/include/asm/rwonce.h b/arch/arm64/include/asm/rwonce.h > > new file mode 100644 > > index 000000000000..515e360b01a1 > > --- /dev/null > > +++ b/arch/arm64/include/asm/rwonce.h > > @@ -0,0 +1,63 @@ > >

On Mon, Jul 06, 2020 at 05:00:23PM +0100, Dave Martin wrote: > On Thu, Jul 02, 2020 at 08:23:02AM +0100, Will Deacon wrote: > > On Wed, Jul 01, 2020 at 06:07:25PM +0100, Dave P Martin wrote: > > > Also, can you illustrate code that can only be unsafe with Clang LTO? > > > > I don't have a concrete example, but it's an ongoing concern over on the LTO > >

On Wed, Jul 01, 2020 at 06:07:25PM +0100, Dave P Martin wrote: > On Tue, Jun 30, 2020 at 06:37:34PM +0100, Will Deacon wrote: > > When building with LTO, there is an increased risk of the compiler > > converting an address dependency headed by a READ_ONCE() invocation > > into a control dependency and consequently allowing for harmful > > reordering by the CPU. > >

On Tue, Jun 30, 2020 at 7:39 PM Will Deacon <will at kernel.org> wrote: > +#define __READ_ONCE(x) \ > +({ \ > + int atomic = 1; \ > + union { __unqual_scalar_typeof(x) __val; char __c[1]; } __u; \ > +

On Tue, Jun 30, 2020 at 7:39 PM Will Deacon <will at kernel.org> wrote: > +#define __READ_ONCE(x) \ > +({ \ > + int atomic = 1; \ > + union { __unqual_scalar_typeof(x) __val; char __c[1]; } __u; \ > +

When building with LTO, there is an increased risk of the compiler converting an address dependency headed by a READ_ONCE() invocation into a control dependency and consequently allowing for harmful reordering by the CPU. Ensure that such transformations are harmless by overriding the generic READ_ONCE() definition with one that provides acquire semantics when building with LTO. Signed-off-by:

When building with LTO, there is an increased risk of the compiler converting an address dependency headed by a READ_ONCE() invocation into a control dependency and consequently allowing for harmful reordering by the CPU. Ensure that such transformations are harmless by overriding the generic READ_ONCE() definition with one that provides acquire semantics when building with LTO. Signed-off-by:

I'm trying to put together a Micro Conference for Linux Plumbers conference focused on "make LLVM slightly less shitty." Do you all plan on attending the conference? Would it be worthwhile to hold a session focused on discussing this (LTO and memory models) be worthwhile? On Tue, Jul 7, 2020 at 3:51 PM Paul E. McKenney <paulmck at kernel.org> wrote: > > On Tue, Jul 07,

I have the following code and data data.csv "","Goal","Frequency","Weight","Group" "1","Move",13,0.245283018867925,"Public" "2","Create",10,0.188679245283019,"Public" "3","Strengthen",30,0.566037735849057,"Public"

On 4/2/2016 11:07 AM, David Winsemius wrote: >> On Apr 1, 2016, at 5:01 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: >> >> On 01/04/2016 6:46 PM, Bert Gunter wrote: >>> ... of course, whether one **should** get them is questionable... >> They're just statistics. How could it hurt to look at them? > Like Rolf, I thought that this utterance

I have been looking at some internal codes looking for differences between Clang (specifically 3.7.1) and gcc (typically 4.8.1 but sometimes later). One area where I bumped into was dead code elimination in the presence of complex control flow. I note that the “aggressive dead code elimination” (ADCE.cpp) treats all branch operations as live (isa<TerminatorInst>(I)). Doing more requires

On Wed, 25 Mar 2009, Vikram S. Adve wrote: > We do have a static array bounds checking algorithm based on the Omega > integer programming library, but it is not hugely effective. I think > this can be strengthened a *lot*. I should add that I would be interested in helping with hooking a good decision procedure into LLVM. This will be useful far beyond array bounds check

...op) Requires: perl(Compress::Bzip2) Can't find perl(compress::bzip2) anywhere. thansk in advance! Fred -- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- I can do all things through Christ who strengthens me. ------------------------------ Philippians 4:13 -------------------------------

Hello, On Sat, Dec 30, 2017 at 12:16 AM, Daniel Kahn Gillmor <dkg at fifthhorseman.net > wrote: > On Thu 2017-12-28 21:31:28 -0800, Dan Mahoney (Gushi) wrote: > > > > Perhaps if you're dead-set on this being so dangerous, > > It's not the developers who are dead-set on weak-keyed RSA being > insecure, it's the cryptanalysts who have shown that to be the