similar to: [LLVMdev] load widening no more?

On Fri, Dec 16, 2011 at 6:08 PM, Kostya Serebryany <kcc at google.com> wrote: > In this case, we have an array of 22 bytes which is 16-aligned. >> I suspect that load widening changed the alignment of alloca instruction >> to make the transformation legal. Right? >> Can we change the load widening algorithm to also change the size of >> alloca instruction to be

On Wed, Dec 28, 2011 at 12:40 PM, Criswell, John T <criswell at illinois.edu>wrote: > Dear All, > > I think adding metadata and expecting transforms to repect it is a bad > idea. It is just too easy for someone who does not know about the metadata > to add a transform that ignores it. > > As for SAFECode, I think we have one of several options for handling >

git://git.zytor.com/users/genec/syslinux.git Branch handoff-mbr-for-hpa This is a piece of code that can be used in place of a MBR or VBR/PBR (master boot record; volume/partition) in order to examine the data handed to the respective boot code. AX, SS, and SP are destroyed before examining anything. I set an internal restriction that limits it to 420 bytes such that it could be used with a

Hi, [resurrecting an old mail thread about AddressSanitizer false positive caused by load widening] Once the Attribute::AddressSafety is set by clang (a separate patch), fixing this bug may look as simple as this: --- lib/Analysis/MemoryDependenceAnalysis.cpp (revision 148708) +++ lib/Analysis/MemoryDependenceAnalysis.cpp (working copy) @@ -323,6 +323,14 @@

On Fri, Dec 16, 2011 at 2:35 PM, Chris Lattner <clattner at apple.com> wrote: > On Dec 16, 2011, at 2:27 PM, Kostya Serebryany wrote: > > This is a good question. Would it be possible for ASan to do its >> instrumentation earlier? >> > > It would be possible but undesirable. > First, asan blows up the IR and running asan early will increase the >

> > This is a good question. Would it be possible for ASan to do its > instrumentation earlier? > It would be possible but undesirable. First, asan blows up the IR and running asan early will increase the compile-time. Second, asan greatly benefits from all optimizations running before it because it needs to instrument less memory accesses. It actually benefits from load widening

________________________________ From: Kostya Serebryany [kcc at google.com] Sent: Wednesday, December 28, 2011 2:46 PM To: Criswell, John T Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] load widening conflicts with AddressSanitizer On Wed, Dec 28, 2011 at 12:40 PM, Criswell, John T <criswell at illinois.edu<mailto:criswell at illinois.edu>> wrote: Dear All, I think adding

Dear All, I think adding metadata and expecting transforms to repect it is a bad idea. It is just too easy for someone who does not know about the metadata to add a transform that ignores it. As for SAFECode, I think we have one of several options for handling load-widening. The most obvious one is to have a pass that just boosts the allocation size of any alloca with an align 16 attribute;

Hi, I noticed a significant performance regression (up to 40%) on some internal CUDA benchmarks (a reduced example presented below). The root cause of this regression seems that IndVarSimpilfy widens induction variables assuming arithmetics on wider integer types are as cheap as those on narrower ones. However, this assumption is wrong at least for the NVPTX64 target. Although the NVPTX64 target

I've been playing around with llvm lately and I was wondering something about the bitcode instructions for basic arithmetic. Is there any plan to provide instructions that perform widening multiply, or add with carry? It might be written as: mulw i32 %lhs %rhs -> i64 ; widening multiply addw i32 %lhs %rhs -> i33 ; widening add addc i32 %lhs, i32 %rhs, i1 %c -> i33 ; add with carry

On 12/16/11 4:35 PM, Chris Lattner wrote: > On Dec 16, 2011, at 2:27 PM, Kostya Serebryany wrote: >> >> This is a good question. Would it be possible for ASan to do its >> instrumentation earlier? >> >> >> It would be possible but undesirable. >> First, asan blows up the IR and running asan early will increase the >> compile-time.

Hi Kostya, > [resurrecting an old mail thread about AddressSanitizer false positive caused by > load widening] > > Once the Attribute::AddressSafety is set by clang (a separate patch), fixing > this bug may look as simple as this: I don't get the point of an attribute. There's plenty of code out there that does wide loads like this directly (without them being created by

On Dec 16, 2011, at 2:27 PM, Kostya Serebryany wrote: > This is a good question. Would it be possible for ASan to do its instrumentation earlier? > > It would be possible but undesirable. > First, asan blows up the IR and running asan early will increase the compile-time. > Second, asan greatly benefits from all optimizations running before it because it needs to instrument

On 12/16/11 7:56 PM, Chris Lattner wrote: > On Dec 16, 2011, at 3:29 PM, John Criswell <criswell at illinois.edu > <mailto:criswell at illinois.edu>> wrote: >> On 12/16/11 4:45 PM, Chris Lattner wrote: >>> >>> On Dec 16, 2011, at 2:41 PM, John Criswell wrote: >>> >>>> On 12/16/11 4:14 PM, Chris Lattner wrote: >>>>> On

On 1/24/12 3:36 PM, Kostya Serebryany wrote: > > > On Tue, Jan 24, 2012 at 1:08 PM, John Criswell <criswell at illinois.edu > <mailto:criswell at illinois.edu>> wrote: > > On 1/24/12 2:31 PM, Duncan Sands wrote: > > Hi Kostya, > > As far as I can see the C and C++ standards are not > relevant. ASAN works on >

----- Original Message ----- > From: "Nadav Rotem" <nrotem at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvmdev at cs.uiuc.edu Dev" <llvmdev at cs.uiuc.edu> > Sent: Wednesday, March 6, 2013 3:40:50 PM > Subject: Re: [LLVMdev] Vector splitting vs widening > > Hi Hal, > > > > > > > The

Hi Chandler, > On Tue, Jan 24, 2012 at 1:36 PM, Kostya Serebryany <kcc at google.com > <mailto:kcc at google.com>> wrote: > > ASAN *can* be modified this way (it will actually make instrumentation ~10% > cheaper). > But this mode will miss some bugs that the current mode finds. > I've seen at least a couple of such *real* bugs. > >

On Dec 19, 2011, at 3:04 PM, John Criswell wrote: >>> The alloca in question allocates 22 bytes. The 64-bit load in Kostya's original email is accessing two additional bytes past the end of the alloca (i.e., it is accessing array "elements" a[22] and a[23]). Accessing that memory with a read or write is undefined behavior. The program could fault, read zeros, read

On 12/16/11 4:14 PM, Chris Lattner wrote: > On Dec 16, 2011, at 12:39 PM, Kostya Serebryany wrote: >> >> > Do we consider the above transformation legal? >> > > Yes, the transformation is perfectly legal for the normal compiler. So how do you guarantee that the behavior is predictable regardless of hardware platform if you don't define what the behavior

On Fri, Dec 16, 2011 at 12:37 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Fri, Dec 16, 2011 at 12:19 PM, John Criswell <criswell at illinois.edu> > wrote: > > On 12/16/11 12:24 PM, Kostya Serebryany wrote: > > > > Hello, > > > > We've just got a bug report from Mozilla folks about AddressSanitizer > false > > positive with