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

Sanjay Patel spatel at rotateright.com
Thu Feb 19 09:38:05 PST 2015


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/






More information about the llvm-commits mailing list