https://github.com/ssahasra closed
https://github.com/llvm/llvm-project/pull/135803
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
/bc1725ef3a2707c244d8c2a401d7545755f96cbd.diff
LOG: [clang] convergent attribute does not require "all threads" (#135803)
The documentation for the `convergent` attribute claims that OpenCL and
CUDA require "all threads" in a group to call the same convergent
operation. This is true only for OpenCL, and in gene
ssahasra wrote:
Taking the liberty to commit this change without waiting for a review. The
change is self-contained, and actually does eliminate a legacy description that
is best left to each language spec.
https://github.com/llvm/llvm-project/pull/135803
_
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Sameer Sahasrabuddhe (ssahasra)
Changes
The documentation for the `convergent` attribute claims that OpenCL and CUDA
require "all threads" in a group to call the same convergent operation. This is
true only for OpenCL, and in general, the
neral, the `convergent` attribute is used in
LLVM IR on operations that have no such constraint.
>From 5024a4e5a9dc92744296cf59db7363602bca1807 Mon Sep 17 00:00:00 2001
From: Sameer Sahasrabuddhe
Date: Tue, 15 Apr 2025 21:43:35 +0530
Subject: [PATCH] [clang] convergent attribute does not require "
Hello,
>>> CUDA? In any case, I don't see how the restriction helps users, and the
>>> attribute at the IR level has a well-defined meaning regardless. If a user
>>> were to have a use case, they'd simply find the restriction arbitrary and
>>> frustrating.
>>
>> Yes, CUDA was already considere
Hello,
>> CUDA? In any case, I don't see how the restriction helps users, and the
>> attribute at the IR level has a well-defined meaning regardless. If a user
>> were to have a use case, they'd simply find the restriction arbitrary and
>> frustrating.
>
> Yes, CUDA was already considered as w
then.
;)
Anastasia
-Original Message-
From: Hal Finkel [mailto:hfin...@anl.gov]
Sent: 10 May 2016 00:33
To: Anastasia Stulova
Cc: nd; Clang Commits; Matt Arsenault; Ettore Speziale; Aaron Ballman
Subject: Re: [Clang] Convergent Attribute
- Original Message -
> From: "An
- Original Message -
> From: "Richard Smith via cfe-commits"
> To: "Matt Arsenault"
> Cc: "Clang Commits"
> Sent: Monday, May 9, 2016 4:45:04 PM
> Subject: Re: [Clang] Convergent Attribute
> On Mon, May 9, 2016 at 2:43 PM, Richard Smit
- Original Message -
> From: "Anastasia Stulova via cfe-commits"
> To: "Matt Arsenault" , "Ettore Speziale"
> , "Aaron Ballman"
>
> Cc: "nd" , "Clang Commits"
> Sent: Monday, May 9, 2016 12:39:19 PM
> Sub
On Mon, May 9, 2016 at 2:43 PM, Richard Smith wrote:
> On Sun, May 8, 2016 at 12:43 PM, Matt Arsenault via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On May 6, 2016, at 18:12, Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>> On Fri, May 6, 2016 at 4:20 PM,
On Sun, May 8, 2016 at 12:43 PM, Matt Arsenault via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> On May 6, 2016, at 18:12, Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> On Fri, May 6, 2016 at 4:20 PM, Matt Arsenault via cfe-commits <
> cfe-commits@lists.llvm.org> w
> On May 9, 2016, at 10:39, Anastasia Stulova via cfe-commits
> wrote:
>
> Since it's not a part of any official spec we could of course make it
> accepted with anything.
>
> Just out of curiosity what other programming models supported by Clang do you
> think this attribute would be useful
> This seems to be a pointless arbitrary restriction to me
Updated the patch based on the review comments:
* allow the [[clang::convergent]] attribute spelling
* used a better example in the documentation
Thanks
--
Ettore Speziale — Compiler Enginee
nault [mailto:matthew.arsena...@amd.com]
Sent: 07 May 2016 00:37
To: Anastasia Stulova; Ettore Speziale; Aaron Ballman
Cc: nd; Clang Commits
Subject: Re: [Clang] Convergent Attribute
On 05/06/2016 12:11 PM, Anastasia Stulova via cfe-commits wrote:
> I was just wondering whether it would make sense to restrict the
> On May 6, 2016, at 18:12, Richard Smith via cfe-commits
> wrote:
>
> On Fri, May 6, 2016 at 4:20 PM, Matt Arsenault via cfe-commits
> mailto:cfe-commits@lists.llvm.org>> wrote:
> On 05/06/2016 02:42 PM, David Majnemer via cfe-commits wrote:
> This example looks wrong to me. It doesn't seem m
On Fri, May 6, 2016 at 4:20 PM, Matt Arsenault via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> On 05/06/2016 02:42 PM, David Majnemer via cfe-commits wrote:
>
>> This example looks wrong to me. It doesn't seem meaningful for a function
>> to be both readonly and convergent, because converge
On 05/06/2016 12:11 PM, Anastasia Stulova via cfe-commits wrote:
I was just wondering whether it would make sense to restrict the usage of the attribute
to OpenCL language i.e. to add "let LangOpts = [OpenCL];" in the attribute
definition.
This seems to be a pointless arbitrary restriction to
On 05/06/2016 02:42 PM, David Majnemer via cfe-commits wrote:
This example looks wrong to me. It doesn't seem meaningful for a
function to be both readonly and convergent, because convergent means
the call has some side-effect visible to other threads and readonly
means the call has no side-eff
On 05/06/2016 02:53 PM, Richard Smith via cfe-commits wrote:
It looks like we added the noduplicate attribute to clang to support
OpenCL's barrier function. Did we get the semantics for it wrong for
its intended use case?
Yes. Noduplicate is essentially deprecated in favor of convergent.
nodupl
all void @j()
>>> ret void
>>>
>>> l5:
>>> call void @k()
>>> ret void
>>> ; CHECK: }
>>> }
>>>
>>> If you do not mark baz convergent, you get this:
>>>
>>> clang -x cl -emit-llvm -S -o
if.then2, label %if.else3
>>
>> if.then2: ; preds = %entry
>> call void @foo0()
>> call void @baz()
>> call void @foo0()
>> br label %if.end4
>>
>> if.else3:
call void @foo0()
> br label %if.end4
>
> if.else3: ; preds = %entry
> call void @foo1()
> call void @baz()
> call void @foo1()
> br label %if.end4
>
> if.end4:
all void @foo1()
br label %if.end4
if.end4: ; preds = %if.else3, %if.then2
ret void
}
Which is illegal, as the value of x might not be the same for all work-items.
I’ll update the patch such as:
* it uses the example about jump-threading
* it marks the attribute available in Open
On Wed, May 4, 2016 at 5:47 PM, Ettore Speziale via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Hello,
>
> > I would appreciate a bit more background on this attribute's
> > semantics. How would a user know when to add this attribute to their
> > function definition? Are there other attribu
Speziale; Anastasia Stulova; Clang Commits
> Subject: Re: [Clang] Convergent Attribute
>
> Hello,
>
> > I would appreciate a bit more background on this attribute's
> > semantics. How would a user know when to add this attribute to their
> > function definition? Ar
eziale.ett...@gmail.com]
Sent: 05 May 2016 01:48
To: Aaron Ballman
Cc: Ettore Speziale; Anastasia Stulova; Clang Commits
Subject: Re: [Clang] Convergent Attribute
Hello,
> I would appreciate a bit more background on this attribute's
> semantics. How would a user know when to add th
Hello,
> I would appreciate a bit more background on this attribute's
> semantics. How would a user know when to add this attribute to their
> function definition? Are there other attributes that cannot be used in
> conjunction with this one? Should this apply to member functions? What
> about Obj
On Tue, May 3, 2016 at 12:18 PM, Ettore Speziale
wrote:
> Hello,
>
> the attached patch introduces the `convergent` attribute.
>
> It is meant to be lowered into the LLVM `convergent` attribute, to restrict
> optimizations of attributed functions — e.g. you can attach convergent to
> OpenCL’s ba
Hello,
the attached patch introduces the `convergent` attribute.
It is meant to be lowered into the LLVM `convergent` attribute, to restrict
optimizations of attributed functions — e.g. you can attach convergent to
OpenCL’s barrier, and thus prevent a call site being moved to another position
30 matches
Mail list logo
