[LLVMdev] [cfe-dev] Proposal: pragma for branch divergence

Owen Anderson resistor at mac.com
Sun Jan 25 19:55:54 PST 2015


> On Jan 25, 2015, at 7:53 PM, Owen Anderson <resistor at mac.com> wrote:
> 
> 
>> On Jan 25, 2015, at 12:31 PM, Jingyue Wu <jingyue at google.com <mailto:jingyue at google.com>> wrote:
>> 
>> Owen, could you explain more on the approach of using branch-if-none instructions in your mind? I believe you have lots of great insights, but I don't see how cbranch.ifnone instructions directly solve my issue. The issue I am trying to solve is that certain CFG optimizations transform the CFG into a "bad" structure which hurts the performance of the compiled code in the presence of divergent branches. On the other hand, I don't want to disable jump threading all together because it is still beneficial for non-divergent branches. As far as I can understand, cbranch.ifnone provides a fast path so that a warp can jump over the region that no threads in the warp ever execute. However, it doesn't help the case where the branches are indeed divergent. 
> 
> I don’t have any specific advice to offer you about JumpThreading.  My experience has been that it generally not worth using for GPU targets.  I suspect that an enhanced model that allowed the target to assign a cost-per-duplication of instructions might make it more profitable.

Also, if you’re interested in optimizations that reduce branch divergence, you might take a look at the following papers.  I have no hands-on experience with them, but they seem like they could be useful, particularly to more general compute applications:

http://www.eecg.toronto.edu/~han/papers/brdiv-gpgpu11.pdf <http://www.eecg.toronto.edu/~han/papers/brdiv-gpgpu11.pdf>
http://www.eecg.toronto.edu/~han/papers/lm-gpgpu13.pdf <http://www.eecg.toronto.edu/~han/papers/lm-gpgpu13.pdf>

—Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150125/18662bdf/attachment.html>


More information about the llvm-dev mailing list