llvm dev - Oct 2019 - RFC: Removal of noduplicate attribute

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.

A related question is if it’s OK to recycle the attribute encoding bit, or if
this will be a problematic bitcode compatibility change.

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191025/c9fc5d3d/attachment.html>

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.

~Aaron
>
> A related question is if it’s OK to recycle the attribute encoding bit, or
if this will be a problematic bitcode compatibility change.
>
>
>
> -Matt
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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.
> > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191029/19711b2d/attachment.sig>

> On Oct 27, 2019, at 10:25, Aaron Ballman via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 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.
The QoI isn’t great for it, and we aren’t seeing any bug reports involving it so
it doesn’t seem like it’s really in use. The only mention of the attribute I
found on bugzilla is a comment mentioning that it exists as possibly being
relevant to solving another problem.

Similar to how clang tries to force convergent on all functions, noduplicate
would have to be speculatively added to all functions if we were serious about
preserving the semantics. As-is calls to noduplicate functions could be
effectively duplicated by duplicating a call to a function that calls a
noduplicate function, or a call to a noduplicate through an indirect call.

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191028/ba9942b1/attachment.html>