search for: sanitizeaddress

On 28 Sep 2016, at 16:50, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > At this point, my general view is that widening transformations of any kind should be done very late. Ideally, this is something the backend would do, but doing it as a CGP like fixup pass over the IR is also reasonable. I’m really glad to see that this is gone in GVN - it will reduce our

...t’s valid to widen loads beyond the extents (for > > example, for us it is not valid to widen an i16 load followed by an i8 > > load to an i32 load). Ideally, we’d also want the back end to supply > > Don't you have to mark the functions you generate as > "Attribute::SanitizeAddress"? We should definitely make the > speculative form of this transform (i.e. "load i32, load i16" --> > "load i64") predicated on Attribute::SanitizeAddress. Nope, we’re not using the address sanitiser. Our architecture supports byte-granularity bounds checking in...

...bling/disabling >>> certain passes)? >>> >> >> Yes. AddressSanitizer and ThreadSanitizer disable load widening that >> would create a partially out-of-bounds or a racy access. >> See lib/Analysis/MemoryDependenceAnalysis.cpp (search for >> Attribute::SanitizeAddress and Attribute::SanitizeThread). >> This case with MemorySanitizer is slightly different because we are not >> fighting a false positive, but rather a debug-info-damaging optimization. >> >> --kcc >> >> >>> If not, does this need some deeper discussion a...

...> certain passes)? >>>> >>> >>> Yes. AddressSanitizer and ThreadSanitizer disable load widening that >>> would create a partially out-of-bounds or a racy access. >>> See lib/Analysis/MemoryDependenceAnalysis.cpp (search for >>> Attribute::SanitizeAddress and Attribute::SanitizeThread). >>> This case with MemorySanitizer is slightly different because we are not >>> fighting a false positive, but rather a debug-info-damaging optimization. >>> >>> --kcc >>> >>> >>>> If not, does this n...

...)? >>>> >>>> >>>> Yes. AddressSanitizer and ThreadSanitizer disable load widening that >>>> would create a partially out-of-bounds or a racy access. >>>> See lib/Analysis/MemoryDependenceAnalysis.cpp (search for >>>> Attribute::SanitizeAddress and Attribute::SanitizeThread). >>>> This case with MemorySanitizer is slightly different because we are not >>>> fighting a false positive, but rather a debug-info-damaging optimization. >>>> >>>> --kcc >>>> >>>>> >>&...

...t;>>>> >>>> >>>> Yes. AddressSanitizer and ThreadSanitizer disable load widening that >>>> would create a partially out-of-bounds or a racy access. >>>> See lib/Analysis/MemoryDependenceAnalysis.cpp (search for >>>> Attribute::SanitizeAddress and Attribute::SanitizeThread). >>>> This case with MemorySanitizer is slightly different because we are not >>>> fighting a false positive, but rather a debug-info-damaging optimization. >>>> >>>> --kcc >>>> >>>> >>>&...

...>>>> > >>>> Yes. AddressSanitizer and ThreadSanitizer disable load widening > >>>> that would create a partially out-of-bounds or a racy access. > >>>> See lib/Analysis/MemoryDependenceAnalysis.cpp (search for > >>>> Attribute::SanitizeAddress and Attribute::SanitizeThread). > >>>> This case with MemorySanitizer is slightly different because we are > >>>> not fighting a false positive, but rather a debug-info-damaging > optimization. > >>>> > >>>> --kcc > >>>>...

...>>>> >>>> >>>> Yes. AddressSanitizer and ThreadSanitizer disable load widening >>>> that would create a partially out-of-bounds or a racy access. >>>> See lib/Analysis/MemoryDependenceAnalysis.cpp (search for >>>> Attribute::SanitizeAddress and Attribute::SanitizeThread). >>>> This case with MemorySanitizer is slightly different because we are >>>> not fighting a false positive, but rather a debug-info-damaging optimization. >>>> >>>> --kcc >>>> >>>>> >>...

...)? >>>> >>>> >>>> Yes. AddressSanitizer and ThreadSanitizer disable load widening >>>> that would create a partially out-of-bounds or a racy access. >>>> See lib/Analysis/MemoryDependenceAnalysis.cpp (search for >>>> Attribute::SanitizeAddress and Attribute::SanitizeThread). >>>> This case with MemorySanitizer is slightly different because we are >>>> not fighting a false positive, but rather a debug-info-damaging optimization. >>>> >>>> --kcc >>>> >>>>> >>&...

...; > >>>> Yes. AddressSanitizer and ThreadSanitizer disable load widening > > >>>> that would create a partially out-of-bounds or a racy access. > > >>>> See lib/Analysis/MemoryDependenceAnalysis.cpp (search for > > >>>> Attribute::SanitizeAddress and Attribute::SanitizeThread). > > >>>> This case with MemorySanitizer is slightly different because we > > >>>> are > > >>>> not fighting a false positive, but rather a debug-info-damaging > > >>>> optimization. > > &gt...

...gt;>>> > >>>> Yes. AddressSanitizer and ThreadSanitizer disable load widening > >>>> that would create a partially out-of-bounds or a racy access. > >>>> See lib/Analysis/MemoryDependenceAnalysis.cpp (search for > >>>> Attribute::SanitizeAddress and Attribute::SanitizeThread). > >>>> This case with MemorySanitizer is slightly different because we > >>>> are > >>>> not fighting a false positive, but rather a debug-info-damaging > >>>> optimization. > >>>> > >&...

.... AddressSanitizer and ThreadSanitizer disable load > > >>>> widening > > >>>> that would create a partially out-of-bounds or a racy access. > > >>>> See lib/Analysis/MemoryDependenceAnalysis.cpp (search for > > >>>> Attribute::SanitizeAddress and Attribute::SanitizeThread). > > >>>> This case with MemorySanitizer is slightly different because > > >>>> we > > >>>> are > > >>>> not fighting a false positive, but rather a > > >>>> debug-info-damaging...

...>>>> > >>>> Yes. AddressSanitizer and ThreadSanitizer disable load widening > >>>> that would create a partially out-of-bounds or a racy access. > >>>> See lib/Analysis/MemoryDependenceAnalysis.cpp (search for > >>>> Attribute::SanitizeAddress and Attribute::SanitizeThread). > >>>> This case with MemorySanitizer is slightly different because we are > >>>> not fighting a false positive, but rather a debug-info-damaging > optimization. > >>>> > >>>> --kcc > >>>>...

On Thu, Nov 12, 2015 at 8:42 PM, Kostya Serebryany <kcc at google.com> wrote: > 2 questions: > - Do you see this with the fresh llvm trunk? > - Can you prepare a minimized example? Pretty recent, I updated a couple days ago. I tried to minimize the attached but at the same time I didn't want to lose too many unions and casts in case it didn't trigger any more. $ clang

Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey

...chineFunction *MF) const { RESET_OPTION(NoNaNsFPMath, "no-nans-fp-math"); RESET_OPTION(UseSoftFloat, "use-soft-float"); RESET_OPTION(DisableTailCalls, "disable-tail-calls"); + RESET_OPTION(HonorFPExceptions, "honor-fp-exceptions"); TO.MCOptions.SanitizeAddress = F->hasFnAttribute(Attribute::SanitizeAddress); } diff --git a/lib/Transforms/InstCombine/InstCombine.h b/lib/Transforms/InstCombine/InstCombine.h index 6c0d4e7..d18309d 100644 --- a/lib/Transforms/InstCombine/InstCombine.h +++ b/lib/Transforms/InstCombine/InstCombine.h @@ -102,6 +102,7 @@ cla...

...t, ///< Stack protection. StackProtectReq, ///< Stack protection required. StackProtectStrong, ///< Strong Stack protection. + SafeStack, ///< Safe Stack protection. StructRet, ///< Hidden pointer to structure to return SanitizeAddress, ///< AddressSanitizer is on. SanitizeThread, ///< ThreadSanitizer is on. diff --git a/include/llvm/InitializePasses.h b/include/llvm/InitializePasses.h index 2964798..76e44f4 100644 --- a/include/llvm/InitializePasses.h +++ b/include/llvm/InitializePasses.h @@ -235,6 +235,7...