llvm dev - Jan 2017 - [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>

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>

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