[llvm-dev] RFC: Removal of noduplicate attribute
Savonichev, Andrew via llvm-dev
llvm-dev at lists.llvm.org
Tue Oct 29 03:56:52 PDT 2019
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.
More information about the llvm-dev