[PATCH] Add intrinsic definitions for unary op AVX instructions [x86]

Demikhovsky, Elena elena.demikhovsky at intel.com
Mon Feb 23 06:21:32 PST 2015


Hi Sanjay,

I fully rewrote the patterns (it took 2 days). But now you'll not need to add intrinsics patterns separately.
Committed revision 230221.

Now you can add r_Int for AVX. I even left "todo" comments for you.
Here: in  "avx_fp_unop_s" definition.

-  Elena

-----Original Message-----
From: Sanjay Patel [mailto:spatel at rotateright.com] 
Sent: Thursday, February 19, 2015 19:38
To: spatel at rotateright.com; nrotem at apple.com; llvm-dev at redking.me.uk; craig.topper at gmail.com; Demikhovsky, Elena
Cc: llvm-commits at cs.uiuc.edu
Subject: Re: [PATCH] Add intrinsic definitions for unary op AVX instructions [x86]

In http://reviews.llvm.org/D6958#126321, @delena wrote:

> You actually can use one class to define all instruction (FR32, FR64) and intrinsics (VR128) using COPY_TO_REGCLASS. in order to convert VR128 to FR32 or FR64.
>  See http://reviews.llvm.org/rL229837.


Hi Elena,

Thanks for the suggestion. But I'm not sure how that applies in this case because the rcp and rsqrt instructions only exist as f32 (not f64). If I am not understanding correctly, can you please provide a code example of how the AVX-512 method would apply here?

> You also can define  V#NAME#SDm_Int, if you don't like the COPY_TO_REGCLASS patterns.

>  There are too many intrinsics. I don't think that we should put them all in the peephole optimization pass.


I agree that we have a mess. But once these intrinsics are defined, we must add them to the peephole load folding table in order to catch the cases in llvm/test/CodeGen/X86/stack-folding-fp-avx1.ll.

The end goal that I was hoping to reach was to reuse this blob of shuffle matching patterns for the unary ops:
http://reviews.llvm.org/diffusion/L/browse/llvm/trunk/lib/Target/X86/X86InstrSSE.td;229871$3166

But now that I'm looking at it again, I don't see a way to do this cleanly. Trying to squeeze the unary ops in with the binary ops will just make everything even more unreadable.

I've checked the test case file in at r229870, so I'll abandon this patch and work on the fix for PR21507 using whatever bits are lying around.


http://reviews.llvm.org/D6958

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/


---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.




More information about the llvm-commits mailing list