<div>Hi,</div><div><br></div><div>I've done work on predicated SIMD representations for LLVM.</div><div><br></div><div>If you search through the archives, you may find my "applymask" proposal, which is an attempt at representing predication in a very comprehensive way. I've since stopped pushing the proposal in part because Larrabee's changing fortunes led to a decline of interest at the time, in part because the proposal doesn't look intuitive to people who don't have experience in SIMD programming, and in part because there were some technical details with my actual proposal (although I believe solutions could be found).</div>
<div><br></div><div>And, in part because a popular trend seems to be to have SIMD units which don't trap or raise exception flags on arithmetic and which don't go faster when predicated, such that there's no  reason to predicate anything except stores and occasionally loads. On these architectures, simply having intrinsics for stores, and perhaps loads, is basically sufficient, and less invasive.</div>
<div><br></div><div>And, in part because predication is another wrinkle for SIMD performance portability. As people start caring more about SIMD performance, there will be more pressure to tune SIMD code in target-specific ways, and it erodes the benefit of a target-independent representation. This is a complex topic though, and there are multiple considerations, and not everyone agrees with me here.</div>
<div><br></div><div>One thing that's initially counter-intuitive is that SIMD predication cannot be done in the same way as scalar or VLIW predication, where the majority of the compiler works as if it's on a "normal" scalar machine and predication happens during codegen, where the optimizer doesn't have to think about it. SIMD predication must be applied by whatever code is producing SIMD instructions, and in LLVM, that's typically in the optimizer or earlier.</div>
<div><br></div>Dan<br><br><div class="gmail_quote">On Fri, Oct 19, 2012 at 8:38 AM, Marcello Maggioni <span dir="ltr"><<a href="mailto:marcello@codeplay.com" target="_blank">marcello@codeplay.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
I'm working on a compiler based on LLVM for a SIMD architecture that supports instruction predication. We would like to implement branching on this architecture using predication.<br>
As you know the LLVM-IR doesn't support instruction predication, so I'm not exactly sure on what is the best way to implement it.<br>
We came up with some ways to do it in LLVM:<br>
<br>
- Do not add any predication in the IR (except for load and stores through intrinsics), linearize the branches and substitute PHI nodes with selects for merging values . In the backend then we would custom lower the select instruction to produce a predicated mov to choose the right version of the value. I think this option doesn't make use of the possible benefits of the architecture we are targeting at all.<br>

<br>
- Another way could be adding intrinsics for all instructions in the target to make them support predication, still linearize all the branches, but use instruction predication instead of generating cmovs . The backend then would custom lower almost any instruction into predicated custom nodes that are matched through tablegen patterns. We could generate these intrinsics in the same IR pass that linearizes branches.<br>

<br>
- Make a custom backend that actually directly outputs predicated instructions (we really mainly only need one type of predicate , so every instruction could use that kind of predicate ...) but I think this is a nasty solution ...<br>

<br>
Did someone already tried to do this in LLVM and if yes what solution/s did you use to solve the problem?<br>
<br>
Regards,<br>
Marcello<br>
<br>
-- <br>
Marcello Maggioni<br>
Codeplay Software Ltd<br>
45 York Place, Edinburgh, EH1 3HP<br>
Tel: 0131 466 0503<br>
Fax: 0131 557 6600<br>
Website: <a href="http://www.codeplay.com" target="_blank">http://www.codeplay.com</a><br>
Twitter: <a href="https://twitter.com/codeplaysoft" target="_blank">https://twitter.com/<u></u>codeplaysoft</a><br>
<br>
This email and any attachments may contain confidential and /or privileged information and is for use by the addressee only. If you are not the intended recipient, please notify Codeplay Software Ltd immediately and delete the message from your computer. You may not copy or forward it,or use or disclose its contents to any other person. Any views or other information in this message which do not relate to our business are not authorized by Codeplay software Ltd, nor does this message form part of any contract unless so stated.<br>

As internet communications are capable of data corruption Codeplay Software Ltd does not accept any responsibility for any changes made to this message after it was sent. Please note that Codeplay Software Ltd does not accept any liability or responsibility for viruses and it is your responsibility to scan any attachments.<br>

Company registered in England and Wales, number: 04567874<br>
Registered office: 81 Linkfield Street, Redhill RH1 6BY<br>
<br>
______________________________<u></u>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a><br>
</blockquote></div><br>