[llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")

[Xinliang David Li via llvm-dev]

On Fri, Feb 26, 2016 at 6:10 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> Hi Sanjoy,
>
> These are both very interesting examples, and demonstrate that the
> problems extends beyond function attributes (encompassing dead-argument
> elimination, etc.).
>
> I'm beginning to think that the best solution, at least when optimizing
> for speed, is the one that David Li suggested: we need to internalize
> functions that have been optimized in certain ways (e.g. instructions with
> potential side effects are removed). The trick here may be to be as
> intelligent about this as possible to minimize the effect on code size.
> Maybe this is as easy as checking whether isSafeToSpeculativelyExecute
> returns false on the deleted instruction? Perhaps when optimizing for size,
> we need to forbid such deletions.
>

In general, if a (multi-TU) function's attribute is changed in any way that
is different from the default 'attribute', the function needs to be
privatized. This is not that different from function cloning during
inter-procedural constant propagation.  Andy mentioned the example about
the function 'attribute' related to modifying caller save registers.

David



>
> Thanks again,
> Hal
>
> ----- Original Message -----
> > From: "Sanjoy Das" <sanjoy at playingwithpointers.com>
> > To: "Hal Finkel" <hfinkel at anl.gov>
> > Cc: "Chandler Carruth" <chandlerc at google.com>, "llvm-dev" <
> llvm-dev at lists.llvm.org>, "Philip Reames"
> > <listmail at philipreames.com>, "Duncan P. N. Exon Smith" <
> dexonsmith at apple.com>
> > Sent: Thursday, February 25, 2016 11:59:27 AM
> > Subject: Re: [llvm-dev] Possible soundness issue with
> available_externally (split from "RFC: Add guard intrinsics")
> >
> > Couple of other examples:
> >
> >   void @foo(i32* %ptr) available_externally {
> >     %discard = load i32, i32* %ptr
> >   }
> >   void bar() {
> >     call @foo(i32* %x)
> >   }
> >
> > ==>
> >
> >   void @foo(i32* %ptr) available_externally {
> >   }
> >   void bar() {
> >     call @foo(i32* %x)
> >   }
> >
> > ==>
> >
> >   void @foo(i32* %ptr) available_externally {
> >   }
> >   void bar() {
> >     call @foo(i32* undef) ;; non optimized @foo will crash
> >   }
> >
> >   ;; Similar example if @foo was dividing something by an integer
> >   ;; argument
> >
> > We've actually seen the above in our VM (though back then we
> > didn't realize that the problem was more general than the one
> > case above).
> >
> > Another one involving `undef` (semantically same as "folding undef",
> > but different enough to state separately):
> >
> >   void @foo(i32* %ptr) available_externally {
> >     store i32 undef, i32* %ptr
> >   }
> >   void bar() {
> >     %val = load i32, i32* %x
> >     call @foo(i32* %x)
> >   }
> >
> > ==>
> >
> >   void @foo(i32* %ptr) readonly available_externally {
> >   }
> >   void bar() {
> >     %val = load i32, i32* %x
> >     call @foo(i32* %x)
> >   }
> >
> > ==>
> >
> >   void @foo(i32* %ptr) readonly available_externally {
> >   }
> >   void bar() {
> >     call @foo(i32* %x)
> >     %val = load i32, i32* %x
> >   }
> >
> > With a non-optimized @foo, %val can be garbage.
> >
> >
> > I'll also note we've not really had bug reports (that I'm aware of)
> > around this issue.  Given that, it is possible that this is a purely
> > theoretical problem.
> >
> > -- Sanjoy
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160226/3d47b3d6/attachment.html>