[LLVMdev] Predication on SIMD architectures and LLVM

Marcello Maggioni marcello at codeplay.com
Fri Oct 19 10:45:52 PDT 2012


Hi Ralf,

yeah, I've checked if on the list there were any kind of reference to 
that , but I only found scattered and incomplete information (maybe some 
good stuff is there, but very well hidden, I will try to check again by 
the way).

About your work on predication, I know of your IR-level if-conversion 
and vectorization and a lot of my knowledge on the matter actually comes 
from your talk in the last Euro-LLVM conference in London, so thanks for 
that! Also thank you for your availability on discussing the matter!

Marcello

On 10/19/2012 5:24 PM, Ralf Karrenberg wrote:
> Hi Marcello,
>
> I am sure I've seen some postings on the list concerning architectures 
> that support predicated execution and how to map that to LLVM IR, I'm 
> just not sure anymore when and who was involved :).
>
> I have implemented your first suggestion for targets that do not have 
> predicated instructions (where control flow to data flow conversion 
> with explicit maintaining of masks and blend operations is the only 
> option you have for SIMD vectorization). However, I agree with you 
> that this is not a good solution for you since you would basically 
> ignore one of the strengths of your platform. Should you still need 
> some code or help with this, feel free to drop me a message.
>
> Cheers,
> Ralf
>
> On 19.10.2012 17:38, Marcello Maggioni wrote:
>> 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




More information about the llvm-dev mailing list