[PATCH] D43783: [OpenCL] Remove block invoke function from emitted block literal struct

Anastasia Stulova via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Oct 30 06:02:05 PDT 2018


Anastasia added a comment.

In https://reviews.llvm.org/D43783#1272001, @AlexeySotkin wrote:

> In https://reviews.llvm.org/D43783#1215573, @Anastasia wrote:
>
> > In https://reviews.llvm.org/D43783#1212485, @yaxunl wrote:
> >
> > > In https://reviews.llvm.org/D43783#1204353, @svenvh wrote:
> > >
> > > > Sorry for digging up an old commit...
> > > >
> > > > Apparently this broke block arguments, e.g. the following test case:
> > > >
> > > >   int foo(int (^ bl)(void)) {
> > > >     return bl();
> > > >   }
> > > >  
> > > >   int get21() {
> > > >     return foo(^{return 21;});
> > > >   }
> > > >  
> > > >   int get42() {
> > > >     return foo(^{return 42;});
> > > >   }
> > > >
> > > >
> > > > In particular, the VarDecl that `getBlockExpr()` sees doesn't have an initializer when the called block comes from an argument (causing clang to crash).
> > >
> > >
> > > Sorry for the delay. I think block should not be allowed as function argument since this generally leads indirect function calls therefore requires support of function pointer. It will rely on optimizations to get rid of indirect function calls.
> >
> >
> > The idea was to allow blocks as function parameters because they are statically known at each function call. This can be resolved later at IR level instead of frontend. I am also not sure there can be other corner cases where it wouldn't work in Clang since we can't leverage analysis passes here. I feel this might be a risky thing to do in Clang. Currently it doesn't work for the examples provided and therefore breaking the compliance with the spec.
>
>
> The spec is not clear about what is "statically determinable". To me, in the example provided we can not resolve the `bl()` call without inlining `foo`, even at IR level. As Sam noted, that leads to indirect call and require support of functions pointers.
>  I see a contradiction in the spec in allowing blocks to be a function argument and disallowing function pointers at the same time. I think maybe the spec should be changed to clarify existing restrictions or add more restrictions for cases when blocks are passed as function argument.


I am  not sure that blocks in function call parameters contradict the rule of them being statically determinable though. You can statically determine what blocks are being passed into a function. There might be multiple different ones though. However, it should be possible to lower the function pointers into the direct calls.


Repository:
  rC Clang

https://reviews.llvm.org/D43783





More information about the cfe-commits mailing list