[llvm-dev] RFC: New function attribute HasInaccessibleState

[Hal Finkel via llvm-dev]

----- Original Message -----
> From: "David Majnemer" <david.majnemer at gmail.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Krzysztof Parzyszek" <kparzysz at codeaurora.org>
> Sent: Friday, December 4, 2015 2:29:21 PM
> Subject: Re: [llvm-dev] RFC: New function attribute HasInaccessibleState
> 
> 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?
> 

Yes, but I agree with your point. It would be good to separate these concepts. Knowing what we can CSE is independent of knowing what may or may not alias with other memory. We could back up some years and re-adopt pure/const as stronger forms of readnone/readonly.

 -Hal

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

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory