[llvm-dev] RFC: New function attribute HasInaccessibleState

[David Majnemer via llvm-dev]

On Fri, Dec 4, 2015 at 12:21 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
>
> > From: "David Majnemer via llvm-dev" <llvm-dev at lists.llvm.org>
> > To: "Krzysztof Parzyszek" <kparzysz at codeaurora.org>
> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
> > Sent: Friday, December 4, 2015 11:16:29 AM
> > Subject: Re: [llvm-dev] RFC: New function attribute
> > HasInaccessibleState
>
> > I'd like to suggest a different direction which should accomplish
> > similar ends.
>
> > I think it would make sense to introduce an attribute: csecandidate.
>
> > If we see a call-site "X" marked as csecandidate, it would imply that
> > it can be replaced with any other call-site "Y" with the same
> > arguments which dominate the call-site at "X".
>
> > However, there are some cases that this would not be able to
> > optimize. For example, if we have two csecandidates ("X" and "Y")
> > which do not dominate one another.
>
> Does this make it different than readnone?
>

Depends on how you define readnone :)

If readnone is supposed to strictly refer to memory (but not other machine
side effects), one might want intrinsics like rdrand to be readnone but not
csecandidate.

I suppose the langref talks about control registers, perhaps that covers
things like rdrand?


>
> > This is solvable using another
> > attribute: speculatable. This attribute would tell us that we can
> > hoist the call out of arbitrary conditions. This would allow us to
> > move our csecandidate call-site to the common dominator of "X" and
> > "Y" and RAUW.
>
> I agree that speculatable would be nice to have.
>
>  -Hal
>
> > On Fri, Dec 4, 2015 at 8:54 AM, Krzysztof Parzyszek via llvm-dev <
> > llvm-dev at lists.llvm.org > wrote:
>
> > > On 12/4/2015 10:48 AM, Vaivaswatha Nagaraj via llvm-dev wrote:
> >
>
> > > > This point however reminds me to add, functions that transitively
> > > > call
> > >
> >
> > > > functions with HasInaccessibleState must also have the flag set.
> > >
> >
>
> > > That's in practice impossible to guarantee, both by the compiler
> > > and
> > > by the programmer.
> >
>
> > > -Krzysztof
> >
>
> > > --
> >
> > > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> > > hosted by The Linux Foundation
> >
>
> > > _______________________________________________
> >
> > > LLVM Developers mailing list
> >
> > > llvm-dev at lists.llvm.org
> >
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> --
>
> --
> 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/20151204/289f8003/attachment.html>