[LLVMdev] Predication on SIMD architectures and LLVM

[Sergei Larin]

We are currently doing something similar to your third option in Hexagon
backend. But it is a VLIW so predication is not the only reason for that.

Sergei

---
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
The Linux Foundation

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Marcello Maggioni
> Sent: Friday, October 19, 2012 10:38 AM
> To: llvmdev at cs.uiuc.edu
> Subject: [LLVMdev] Predication on SIMD architectures and LLVM
> 
> Hello,
> 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.
> 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.
> We came up with some ways to do it in LLVM:
> 
> - 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.
> 
> - 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.
> 
> - 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 ...
> 
> Did someone already tried to do this in LLVM and if yes what solution/s
> did you use to solve the problem?
> 
> Regards,
> Marcello
> 
> --
> Marcello Maggioni
> Codeplay Software Ltd
> 45 York Place, Edinburgh, EH1 3HP
> Tel: 0131 466 0503
> Fax: 0131 557 6600
> Website: http://www.codeplay.com
> Twitter: https://twitter.com/codeplaysoft
> 
> 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.
> 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.
> Company registered in England and Wales, number: 04567874 Registered
> office: 81 Linkfield Street, Redhill RH1 6BY
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev