Wael Yehia via llvm-dev
2017-Jan-17 23:36 UTC
[llvm-dev] [RFC] IR-level Region Annotations
Hi. Regarding the token approach, I've read some documentation (review D11861, EH in llvm, and Reid and David's presentation) but couldn't answer the following question.Does the intrinsic or the instruction returning a token type object act as a code motion barrier? In other words, does it prevent other operations from being reordered with it?If the answer is no, then does it mean the intrinsic has to be marked with the convergent property to achieve the code motion barrier effect?If yes, can someone explain how is that achieved in llvm? Greatly appreciated. Thanks. Wael -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170117/5ecd48ad/attachment.html>
Hal Finkel via llvm-dev
2017-Jan-18 00:36 UTC
[llvm-dev] [RFC] IR-level Region Annotations
On 01/17/2017 05:36 PM, Wael Yehia via llvm-dev wrote:> Hi. Regarding the token approach, I've read some documentation > (review D11861, EH in llvm, and Reid and David's presentation) but > couldn't answer the following question. > Does the intrinsic or the instruction returning a /token/ type object > act as a code motion barrier? In other words, does it prevent other > operations from being reordered with it? > If the answer is no, then does it mean the intrinsic has to be marked > with the /convergent/ property to achieve the code motion barrier effect?To clarify, convergent does not form a code-motion barrier. It prevents transformations from adding additional control dependencies. I suspect that the token type does the same (because tokens can't appear in PHIs). Actual code motion barriers are generally achieved by adding unknown memory dependencies. -Hal> If yes, can someone explain how is that achieved in llvm? > Greatly appreciated. Thanks. > > Wael > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170117/54c7fcf3/attachment.html>
Mehdi Amini via llvm-dev
2017-Jan-18 00:59 UTC
[llvm-dev] [RFC] IR-level Region Annotations
> On Jan 17, 2017, at 4:36 PM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On 01/17/2017 05:36 PM, Wael Yehia via llvm-dev wrote: >> Hi. Regarding the token approach, I've read some documentation (review D11861, EH in llvm, and Reid and David's presentation) but couldn't answer the following question. >> Does the intrinsic or the instruction returning a token type object act as a code motion barrier? In other words, does it prevent other operations from being reordered with it? >> If the answer is no, then does it mean the intrinsic has to be marked with the convergent property to achieve the code motion barrier effect? > > To clarify, convergent does not form a code-motion barrier. It prevents transformations from adding additional control dependencies. I suspect that the token type does the same (because tokens can't appear in PHIs).What if the only user of the token is in a branch? It seems to me that you’d be allowed to sink the token producer there, but not if it is marked convergent. — Mehdi> > Actual code motion barriers are generally achieved by adding unknown memory dependencies. > > -Hal > >> If yes, can someone explain how is that achieved in llvm? >> Greatly appreciated. Thanks. >> >> Wael >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > > -- > Hal Finkel > Lead, Compiler Technology and Programming Languages > Leadership Computing Facility > Argonne National Laboratory > _______________________________________________ > 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/20170117/bc5473ee/attachment.html>