Hello guys,
>> Should we deprecate noduplicate then as convergent should cover both use
>> cases for OpenCL I believe? As far as I understand noduplicate was added
>> specifically for SPMD use cases...
>
> noduplicate has different semantics than convergent. Although it is proposed
> for SPMD
Hello,
> As far as I understand the whole problem is that the optimized functions are
> marked by __attribute__((pure)). If the attribute is removed from your
> example, we get LLVM dump preserving correctness:
>
> define i32 @bar(i32 %x) local_unnamed_addr #0 {
> entry:
> %call = tail call i3
Ping
> Gently ping.
>
>> On Aug 26, 2015, at 2:40 PM, Ettore Speziale
>> wrote:
>>
>> Forward to the right ML:
>>
Sorry about the extreme delay. This patch slipped through the cracks, and
I only noticed it again when searching my email for enable_if. Committed
in r245985! In
Hello,
sorry for the late reply, I did not note this email …
> Sure. :) Review is based off the attachment I grabbed from here:
> http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20150824/136904.html
That’s correct.
> A few nits:
> - test/Sema/enable_if.cpp line 24: Please use __attri
Hello,
> It looks like the attached patch is the same as the original one?
I’ve attache the wrong patch. Here is the right one:
enable-if.diff
Description: Binary data
Thanks,
Ettore Speziale___
cfe-commits mailing list
cfe-commits@lists.llvm.org
ht
Hello,
> Looks good to me!
>
> Do you have commit access, or would you like for me to commit it for you?
I do not have commit access. It would be great if you can commit for me.
Thanks,
Ettore Speziale
___
cfe-commits mailing list
cfe-commits@lists.ll
Forward to the right ML:
>> Sorry about the extreme delay. This patch slipped through the cracks, and I
>> only noticed it again when searching my email for enable_if. Committed in
>> r245985! In the future, please feel free to continue pinging weekly!
>
> NP, thank you for committing the patch
Gently ping.
> On Aug 26, 2015, at 2:40 PM, Ettore Speziale
> wrote:
>
> Forward to the right ML:
>
>>> Sorry about the extreme delay. This patch slipped through the cracks, and I
>>> only noticed it again when searching my email for enable_if. Committed in
>>> r245985! In the future, please
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
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
Hello,
> In the case of foo, there could be a problem.
> If you do not mark it convergent, the LLVM sink pass push the call to foo to
> the then branch of the ternary operator, hence the program has been
> incorrectly optimized.
>
> Really? It looks like the problem is that you lied to the comp
Hello,
> 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 arbitr
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
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
14 matches
Mail list logo
