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

Johannes Doerfert via llvm-dev llvm-dev at lists.llvm.org
Fri Jan 20 05:32:14 PST 2017


On 01/11, Daniel Berlin via llvm-dev wrote:
> >
> > def int_experimental_directive : Intrinsic<[], [llvm_metadata_ty],
> >                                    [IntrArgMemOnly],
> > "llvm.experimental.directive">;
> >
> > def int_experimental_dir_qual : Intrinsic<[], [llvm_metadata_ty],
> > [IntrArgMemOnly],
> > "llvm.experimental.dir.qual">;
> >
> > def int_experimental_dir_qual_opnd : Intrinsic<[],
> > [llvm_metadata_ty, llvm_any_ty],
> > [IntrArgMemOnly],
> > "llvm.experimental.dir.qual.opnd">;
> >
> > def int_experimental_dir_qual_opndlist : Intrinsic<
> >                                         [],
> > [llvm_metadata_ty, llvm_vararg_ty],
> > [IntrArgMemOnly],
> > "llvm.experimental.dir.qual.opndlist">;
> >
> >
> I'll bite.
> 
> What does argmemonly mean when the operands are metadata/?
> :)
> 
> If the rest is an attempt to keep the intrinsic from being floated or
> removed, i'm strongly against extending a way we already know to have
> significant effect on optimization (fake memory dependence) to do this.
> Particularly for something so major.

I guess that any kind of extension that does pretend to have some sort
of side effect will have a significant effect on optimizations. The
tricky part is to find the right representation (and side effects) that
implicitly keep the semantics/invariants of parallel code preserved
while allowing as much transformations as possible.

[The following paragraph might be a bit abstract. If it is unclear
 please tell me and I will add a code example.]

In the example by Sanjoy [0] we saw that "parallel regions markers" need
to be a barrier for alloca movement, though we might want some
transformations to "move" them nevertheless, e.g., to aggregate in
parallel executed allocas outside the parallel region as a means of
communication. To make a transformation like this happening but prevent
the movement Sanjoy described at the same time, we probably have to
educate some passes on the semantics of "parallel region markers".
Alternatively, (my hope is that) if we use use known concepts (mainly
dominance) to encode parts of the parallel invariants such optimizations
should come at a much lower cost.

Cheers,
  Johannes

[0] http://lists.llvm.org/pipermail/llvm-dev/2017-January/109302.html

> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


-- 

Johannes Doerfert
Researcher / PhD Student

Compiler Design Lab (Prof. Hack)
Saarland Informatics Campus, Germany
Building E1.3, Room 4.31

Tel. +49 (0)681 302-57521 : doerfert at cs.uni-saarland.de
Fax. +49 (0)681 302-3065  : http://www.cdl.uni-saarland.de/people/doerfert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: Digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170120/79802694/attachment.sig>


More information about the llvm-dev mailing list