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

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 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

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

________________________________________
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
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On Tue, Oct 29, 2019 at 11:57 AM Savonichev, Andrew via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> > 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.
I don't quite understand the reasoning behind this. Is it because your
backend turns each individual barrier call into a large chunk of code?

If so, would it be a long-term viable alternative to inform the
various code size heuristics about this instead of using
`noduplicate`?

Cheers,
Nicolai
-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.