David Majnemer via llvm-dev
2015-Dec-04 17:16 UTC
[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. 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.
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151204/19233c23/attachment.html>
Hal Finkel via llvm-dev
2015-Dec-04 20:21 UTC
[llvm-dev] RFC: New function attribute HasInaccessibleState
----- 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?> 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
David Majnemer via llvm-dev
2015-Dec-04 20:29 UTC
[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?> > > 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>