search for: caller_a

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 t...

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_divi...

...5:21 PM, Sanjoy 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-...

...t playingwithpointers.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...

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

> 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