[llvm-dev] RFC: Removal of noduplicate attribute

[Savonichev, Andrew via llvm-dev]

On 10/29, Doerfert, Johannes wrote:
> Do you properly annotate all functions in the call chain with `noduplicate` or only barriers as a "hint"?
> I mean what the loop below, would it be unrolled or is `noduplicate` also applied to `foo`?
>
> ```
> void foo() { barrier(); }
>
> for (...) {
>   // some code
>   foo() ;
> }
> ```
>
> Cheers,
>   Johannes

Yes, `noduplicate' is propagated up the call chain, so `foo' should also
be marked as `noduplicate'.

>
> ________________________________________
> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Savonichev, Andrew via llvm-dev <llvm-dev at lists.llvm.org>
> Sent: Tuesday, October 29, 2019 05:56
> To: llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] RFC: Removal of noduplicate attribute
>
> On 10/29, Doerfert, Johannes via llvm-dev wrote:
> > On 10/27, Aaron Ballman via llvm-dev wrote:
> > > On Fri, Oct 25, 2019 at 7:37 PM Arsenault, Matthew via llvm-dev
> > > <llvm-dev at lists.llvm.org> wrote:
> > > >
> > > > Hi,
> > > >
> > > > Can the noduplicate attribute be deleted? It was originally added to
> > > > satisfy the constraints of OpenCL barriers, but it didn't really
> > > > solve this problem. Convergent is strictly better and more
> > > > accurately captures the real restriction. Is anyone still using
> > > > noduplicate or really needs the semantics of noduplicate? There are
> > > > a number of passes that now respect convergent, but do not try to
> > > > handle noduplicate properly. There is a maintenance cost to keeping
> > > > it around, and does require work to keep it working as advertised.
> > >
> > > The noduplicate attribute is user-facing and is not tied to OpenCL
> > > (there are no constraints for it, anyway), so I would be suspicious of
> > > removing it just because it doesn't satisfy OpenCL needs -- users may
> > > be using it for other purposes. It may be reasonable to deprecate it
> > > if there is a better user-facing option for users to use and
> > > eventually remove the attribute when we think it's safe to do so, but
> > > I think it's a bit early to talk about removal.
> >
> > These are good points. I think the first question should be: Do we know
> > of any active users of this attribute right now? If not, deprecation
> > seems like something we could do, e.g., through a warning in clang and
> > in the middle-end to ensure other front-ends are aware of it as well.
>
> Noduplicate attribute is still used by the Intel OpenCL Compiler for CPU.
> The main use case is to prevent loop unroll when an OpenCL barrier is called
> within a loop. Although such loop can be unrolled and keep its semantic intact, but
> this introduces a lot of distinct barrier calls, and each of them has to
> be handled separately.
>
> In other words, "noduplicate" serves as a hint to not unroll a loop if a
> certain function is called in a loop body.
>
> >
> > > > A related question is if it's OK to recycle the attribute encoding
> > > > bit, or if this will be a problematic bitcode compatibility change.
> >
> > I doubt it is all that helpful to do so but potentially problematic. We
> > can support a variable number now and we already crossed the critical
> > threshold so I would, for now, argue against reusing old bits.
> >
> > Cheers,
> >   Johannes

--
Andrew