[llvm-dev] [RFC] Refinement of convergent semantics
Mehdi Amini via llvm-dev
llvm-dev at lists.llvm.org
Wed Sep 23 15:57:11 PDT 2015
> On Sep 22, 2015, at 2:36 PM, Owen Anderson via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
>
>> On Sep 22, 2015, at 2:02 PM, Jingyue Wu <jingyue at google.com <mailto:jingyue at google.com>> wrote:
>>
>> Is LLVM allowed to unroll
>>
>> for (int i = 0; i < 4; ++i) {
>> if (i < c) // c is loop invariant
>> convergent();
>> }
>>
>> to
>>
>> if (0 < c)
>> convergent();
>> if (1 < c)
>> convergent();
>> if (2 < c)
>> convergent();
>> if (3 < c)
>> convergent();
>>
>> ?
>>
>> Is "0 < c" considered "an additional value"? I'd vote no, but one can argue the other way.
>
> My intuition agrees with you here, but I don’t know how to formalize it.
>
Introducing intermediate steps in the transformation? If the first transformation is valid, it seems trivial to get the end one:
for (int i = 0; i < 1; ++i) {
if (i < c) // c is loop invariant
convergent();
}
for (int i = 1; i < 2; ++i) {
if (i < c) // c is loop invariant
convergent();
}
for (int i = 2; i < 3; ++i) {
if (i < c) // c is loop invariant
convergent();
}
for (int i = 3; i < 4; ++i) {
if (i < c) // c is loop invariant
convergent();
}
—
Mehdi
>> One approach (Bjarke's idea) to work around such ambiguities is to define: a program is convergent-correct if everything marked convergent are indeed convergent. Then a transformation is convergent-correct unless it transforms a convergent-correct program to a convergent-incorrect one. However, defining "convergent-correct" involves SIMT concepts which you want to avoid here.
>
> There are situations where this is over-conservative as well. Some convergent operations do not require uniformity per se. For example, a gradient operation in graphics programming models requires that all four threads in a given quad are either all executing or all not executing, though a warp is generally larger than that. Restricting convergent code motion to only be between uniform control flow points in the program would penalize that use case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150923/3573b634/attachment.html>
More information about the llvm-dev
mailing list