[LLVMdev] Best way to get direct memory for intrinsics in tblgen?

[Mehdi Amini]

> On Jun 15, 2015, at 7:05 AM, Ryan Taylor <ryta1203 at gmail.com> wrote:
> 
> To be more specific:
> 
> We have some operators that we are currently implementing as intrinsics, for example things like: abs, min, max, etc.....
> 
> for some code:
> 
> int a;
> 
> int food()
> {
>     return abs(a);
> }
> 
> the corresponding operator should look something like:
> 
> abs $a, r0
> 
> however, it looks like since intrinsics are handled as 'calls', we end up with something like:
> 
> mov $a, r0
> abs r0, r0
> 
> Would it be better to make 'abs' an operator as opposed to an intrinsic, or is it possible in LLVM to support direct mem loads/stores via intrinsics?
> 
> I realize that we could resolve this with some peephole opts, I just want to know if there is a way in LLVM to get the 'abs $a, r0' match directly through tblgen?


I assume that what you mean by “operator” is called “machine instruction” in LLVM. 
It seems from the snippet you show "abs r0, r0” that the intrinsic call is correctly turned into a native instruction and not a runtime call, so the intrinsic is somehow matched.

What pattern have you tried to match the sequence abs(load(x)) in tblgen?
If you try to grep for “load” in the X86 backend tblgen files you should find examples of pattern.


— 
Mehdi


> 
> Thanks.
> 
> On Wed, Jun 10, 2015 at 8:19 PM, Ryan Taylor <ryta1203 at gmail.com <mailto:ryta1203 at gmail.com>> wrote:
> What's the best way to get direct memory accesses for intrinsics via tblgen?
> 
> We have some instructions represented as intrinsics. These instructions allow direct memory access, I've tried multiclasses but they won't match. I've also tried "def : Pat<....> but it won't recognize the complex pattern as a valid operand?
> 
> Thanks.
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150616/352108f4/attachment.html>