[PATCH] D36327: [OpenCL] Allow targets emit optimized pipe functions for power of 2 type sizes

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

In https://reviews.llvm.org/D36327#835153, @b-sumner wrote:

> In https://reviews.llvm.org/D36327#834032, @Anastasia wrote:
>
> > In https://reviews.llvm.org/D36327#833891, @yaxunl wrote:
> >
> > > In https://reviews.llvm.org/D36327#833653, @bader wrote:
> > >
> > > > Hi Sam,
> > > >
> > > > What do you think about implementing this optimization in target specific optimization pass? Since size/alignment is saved as function parameter in LLVM IR, the optimization can be done in target specific components w/o adding additional conditions to generic library.
> > > >
> > > > Thanks,
> > > > Alexey
> > >
> > >
> > > Hi Alexey,
> > >
> > > The optimization of the power-of-2 type size is implemented as a library function. Our backend lacks the capability to link in library code at ISA level, so linking of the optimized library function has to be done before any target-specific passes. It seems the only place to do this is Clang codegen since Clang/llvm does not support target-specific pre-linking passes.
> >
> >
> > My general feeling is that it doesn't look like a generic enough change for the frontend. Even though it is implemented in a generic way, not every target might have a special support for the power of 2 size and also if there is such a support not every implementation would handle it as a library function. But I can see that perhaps LLVM is missing flexibility in the flow to accommodate these needs. Any change we could try to extend the compilation flow such that this target specific optimization could happen before the IR linking?
>
>
> It is trivial to implement the small number of specialized functions this patch adds in terms of the general one if desired, and the general one can continue to be handled as it had been.
>
> We had actually proposed a patch (sorry I don't have the reference handy) to add general mechanism for targets to introduce pre-link passes, but it was not accepted.  We can try again, but I don't really expect more progress.


It would be nice to understand why it has not been accepted and whether we could try to argument using this case as an example. It seems like a useful feature for toolchains with the IR linking.


https://reviews.llvm.org/D36327