search for: dseed

So in this case, ptr[0] = 10 is propagated into one copy of maybe_devide (in source a), and ptr[0]=10 in caller_a is DSEed ? David On Sat, Feb 27, 2016 at 1:41 PM, Sanjoy Das via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Just as a reality check, I wrote up a demonstration where one link > order causes a SIGFPE and another doesn't (and the program is well > defined, as far as I can tell). Al...

On Sat, Feb 27, 2016 at 4:21 PM, Xinliang David Li <xinliangli at gmail.com> wrote: > So in this case, ptr[0] = 10 is propagated into one copy of maybe_devide (in > source a), and ptr[0]=10 in caller_a is DSEed ? `ptr[0] = 10` is not really propagated anywhere. What happens is that `source-a` 's copy of `maybe_divide` gets optimized to a `ret (unsigned) ptr` (after inlining in the body of `always_false`)[1], so it is able to DSE the store `ptr[0] = 10`. But `source-b` s copy of `maybe_divide` still...

...joy Das <sanjoy at playingwithpointers.com> wrote: > On Sat, Feb 27, 2016 at 4:21 PM, Xinliang David Li <xinliangli at gmail.com> > wrote: > > So in this case, ptr[0] = 10 is propagated into one copy of maybe_devide > (in > > source a), and ptr[0]=10 in caller_a is DSEed ? > > `ptr[0] = 10` is not really propagated anywhere. What happens is that > `source-a` 's copy of `maybe_divide` gets optimized to a `ret > (unsigned) ptr` (after inlining in the body of `always_false`)[1], so > it is able to DSE the store `ptr[0] = 10`. But `source-b` s copy...

...hpointers.com>> wrote: > On Sat, Feb 27, 2016 at 4:21 PM, Xinliang David Li <xinliangli at gmail.com <mailto:xinliangli at gmail.com>> wrote: > > So in this case, ptr[0] = 10 is propagated into one copy of maybe_devide (in > > source a), and ptr[0]=10 in caller_a is DSEed ? > > `ptr[0] = 10` is not really propagated anywhere. What happens is that > `source-a` 's copy of `maybe_divide` gets optimized to a `ret > (unsigned) ptr` (after inlining in the body of `always_false`)[1], so > it is able to DSE the store `ptr[0] = 10`. But `source-b` s cop...

Just as a reality check, I wrote up a demonstration where one link order causes a SIGFPE and another doesn't (and the program is well defined, as far as I can tell). All TUs are compiled with -O3. This is also an instance where we don't actually speculate an inline function, but only DSE across it (after deducing readnone). Here's the link https://github.com/sanjoy/comdat-ipo

...;target-cpu"="knl" >>>> "target-features"="+adx,+aes,+avx,+avx2,+avx512cd,+avx512er, >>>> +avx512f,+avx512pf,+bmi,+bmi2,+cx16,+f16c,+fma,+fsgsbase,+fx >>>> sr,+lzcnt,+mmx,+movbe,+pclmul,+popcnt,+prefetchwt1,+rdrnd,+r >>>> dseed,+rtm,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+x87,+xsave,+xsaveopt" >>>> "unsafe-fp-math"="false" "use-soft-float"="false" } >>>> >>>> !llvm.ident = !{!0} >>>> >>>> !0 = !{!"clang version 4...

...; >>>>>> "target-features"="+adx,+aes,+avx,+avx2,+avx512cd,+avx512er, >>>>>> +avx512f,+avx512pf,+bmi,+bmi2,+cx16,+f16c,+fma,+fsgsbase,+fx >>>>>> sr,+lzcnt,+mmx,+movbe,+pclmul,+popcnt,+prefetchwt1,+rdrnd,+r >>>>>> dseed,+rtm,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+x87,+xsave,+xsaveopt" >>>>>> "unsafe-fp-math"="false" "use-soft-float"="false" } >>>>>> >>>>>> !llvm.ident = !{!0} >>>>>> >>>&g...

...r-size"="8" "target-cpu"="knl" >> "target-features"="+adx,+aes,+avx,+avx2,+avx512cd,+avx512er, >> +avx512f,+avx512pf,+bmi,+bmi2,+cx16,+f16c,+fma,+fsgsbase,+fx >> sr,+lzcnt,+mmx,+movbe,+pclmul,+popcnt,+prefetchwt1,+rdrnd,+ >> rdseed,+rtm,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+x87,+xsave,+xsaveopt" >> "unsafe-fp-math"="false" "use-soft-float"="false" } >> >> !llvm.ident = !{!0} >> >> !0 = !{!"clang version 4.0.0 (tags/RELEASE_400/final)"} &gt...

...t; "target-features"="+adx,+aes,+avx,+avx2,+avx512cd,+avx512er, >>>>>>>> +avx512f,+avx512pf,+bmi,+bmi2,+cx16,+f16c,+fma,+fsgsbase,+fx >>>>>>>> sr,+lzcnt,+mmx,+movbe,+pclmul,+popcnt,+prefetchwt1,+rdrnd,+r >>>>>>>> dseed,+rtm,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+x87,+xsave,+xsaveopt" >>>>>>>> "unsafe-fp-math"="false" "use-soft-float"="false" } >>>>>>>> >>>>>>>> !llvm.ident = !{!0} >>>&gt...

> On Feb 25, 2016, at 11:41 AM, James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > While we're talking about this, I'd just mention again that the same issue arises for *normal* functions too, when linked into a shared library: > int foo() { return 1; } > int bar() { return foo(); } > > Now, compare: > clang -fPIC -O1 -S -o - test.c