llvm dev - Jan 2017 - [RFC] IR-level Region Annotations

On Wed, Jan 11, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
>
> Can you elaborate why? I’m curious.
>
The con of proposal c was that many passes would need to learn about many
region intrinsics. With tokens, you only need to teach all passes about
tokens, which they should already know about because WinEH and other things
use them.

With tokens, we can add as many region-introducing intrinsics as makes
sense without any additional cost to the middle end. We don't need to make
one omnibus region intrinsic set that describes every parallel loop
annotation scheme supported by LLVM. Instead we would factor things
according to other software design considerations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170112/e686b7ca/attachment.html>

On 01/12/2017 06:20 PM, Reid Kleckner via llvm-dev
wrote:
> On Wed, Jan 11, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com 
> <mailto:mehdi.amini at apple.com>> wrote:
>
>     Can you elaborate why? I’m curious.
>
>
> The con of proposal c was that many passes would need to learn about 
> many region intrinsics. With tokens, you only need to teach all passes 
> about tokens, which they should already know about because WinEH and 
> other things use them.
>
> With tokens, we can add as many region-introducing intrinsics as makes 
> sense without any additional cost to the middle end. We don't need to 
> make one omnibus region intrinsic set that describes every parallel 
> loop annotation scheme supported by LLVM. Instead we would factor 
> things according to other software design considerations.
I think that, unless we allow frontends to add their own intrinsics 
without recompiling LLVM, this severely restricts the usefulness of this 
feature. The motivation here is to support frontends inserting custom 
region annotations which are handled by custom passes the frontends 
inject into the (end of the) pipeline.

  -Hal
>
>
> _______________________________________________
> 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/20170112/2363f9e0/attachment.html>

> On Jan 12, 2017, at 4:20 PM, Reid Kleckner <rnk at google.com> wrote:
> 
> On Wed, Jan 11, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com
<mailto:mehdi.amini at apple.com>> wrote:
> Can you elaborate why? I’m curious.
> 
> The con of proposal c was that many passes would need to learn about many
region intrinsics. With tokens, you only need to teach all passes about tokens,
which they should already know about because WinEH and other things use them.
> 
> With tokens, we can add as many region-introducing intrinsics as makes
sense without any additional cost to the middle end. We don't need to make
one omnibus region intrinsic set that describes every parallel loop annotation
scheme supported by LLVM. Instead we would factor things according to other
software design considerations.
Thanks for explaining!

— 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170112/6d4457d5/attachment.html>

> On Jan 12, 2017, at 5:02 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> On 01/12/2017 06:20 PM, Reid Kleckner via llvm-dev wrote:
> 
>> On Wed, Jan 11, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at
apple.com <mailto:mehdi.amini at apple.com>> wrote:
>> Can you elaborate why? I’m curious.
>> 
>> The con of proposal c was that many passes would need to learn about
many region intrinsics. With tokens, you only need to teach all passes about
tokens, which they should already know about because WinEH and other things use
them.
>> 
>> With tokens, we can add as many region-introducing intrinsics as makes
sense without any additional cost to the middle end. We don't need to make
one omnibus region intrinsic set that describes every parallel loop annotation
scheme supported by LLVM. Instead we would factor things according to other
software design considerations.
> 
> I think that, unless we allow frontends to add their own intrinsics without
recompiling LLVM, this severely restricts the usefulness of this feature.
I’m not convinced that “building a frontend without recompiling LLVM while
injecting custom passes” is a strong compelling use-case, i.e. can you explain
why requiring such use-case/frontends to rebuild LLVM is so limiting?

Thanks,

— 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170112/c455986d/attachment.html>