[LLVMdev] Predication on SIMD architectures and LLVM

[Dan Gohman]

Hi,

I've done work on predicated SIMD representations for LLVM.

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).

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.

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.

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.

Dan

On Fri, Oct 19, 2012 at 8:38 AM, Marcello Maggioni <marcello at codeplay.com>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<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<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121019/74f16581/attachment.html>