search for: movlhp

...rote: > For example, I want to be able to do this: > > defm MOVH : > vs1x_fps_binary_vv_node_rmonly< > 0x16, "movh", undef, 0, > // rr > [(undef)], > // rm > [(set DSTREGCLASS:$dst, > (DSTTYPE (movlhps SRCREGCLASS:$src1, > (DSTTYPE (bitconvert > (v2f64 (scalar_to_vector > (loadf64 addr:$src2))))))))], > // rr Pat > [], >...

...a set of Pat<> patterns in a generic way? For example, I want to be able to do this: defm MOVH : vs1x_fps_binary_vv_node_rmonly< 0x16, "movh", undef, 0, // rr [(undef)], // rm [(set DSTREGCLASS:$dst, (DSTTYPE (movlhps SRCREGCLASS:$src1, (DSTTYPE (bitconvert (v2f64 (scalar_to_vector (loadf64 addr:$src2))))))))], // rr Pat [], // rm Pat [[...

The TableGen language seems to be growing Lisp macros from two different directions. Che-Liang Chiou added a preprocessor with for loops, and David Greene added multidefs. It seems that some kind of macro facility is needed, perhaps we should discuss what it is supposed to look like? /jakob

...e able to do this: >> >> defm MOVH : >> vs1x_fps_binary_vv_node_rmonly< >> 0x16, "movh", undef, 0, >> // rr >> [(undef)], >> // rm >> [(set DSTREGCLASS:$dst, >> (DSTTYPE (movlhps SRCREGCLASS:$src1, >> (DSTTYPE (bitconvert >> (v2f64 (scalar_to_vector >> (loadf64 addr:$src2))))))))], >> // rr Pat >>...

...t; >>> defm MOVH : >>> vs1x_fps_binary_vv_node_rmonly< >>> 0x16, "movh", undef, 0, >>> // rr >>> [(undef)], >>> // rm >>> [(set DSTREGCLASS:$dst, >>> (DSTTYPE (movlhps SRCREGCLASS:$src1, >>> (DSTTYPE (bitconvert >>> (v2f64 (scalar_to_vector >>> (loadf64 addr:$src2))))))))], >>> // rr Pat >&...

...> For example, I want to be able to do this: > > defm MOVH : > vs1x_fps_binary_vv_node_rmonly< > 0x16, "movh", undef, 0, > // rr > [(undef)], > // rm > [(set DSTREGCLASS:$dst, > (DSTTYPE (movlhps SRCREGCLASS:$src1, > (DSTTYPE (bitconvert > (v2f64 (scalar_to_vector > (loadf64 addr:$src2))))))))], > // rr Pat > [], >...

On Sun, Jan 4, 2015 at 3:20 PM, Simon Pilgrim <llvm-dev at redking.me.uk> wrote: > On 24 Nov 2014, at 17:53, Chandler Carruth <chandlerc at gmail.com> wrote: > > > I'll be skimming the PRs to see if there are any really critical > regressions, but so far it looks pretty good. > > > > If you are actively disabling the new vector shuffling and have some PR

...e a set of Pat<> patterns in a generic way? For example, I want to be able to do this: defm MOVH : vs1x_fps_binary_vv_node_rmonly< 0x16, "movh", undef, 0, // rr [(undef)], // rm [(set DSTREGCLASS:$dst, (DSTTYPE (movlhps SRCREGCLASS:$src1, (DSTTYPE (bitconvert (v2f64 (scalar_to_vector (loadf64 addr:$src2))))))))], // rr Pat [], // rm Pat [[...

...: >>>> vs1x_fps_binary_vv_node_rmonly< >>>>   0x16, "movh", undef, 0, >>>>          // rr >>>>          [(undef)], >>>>          // rm >>>>          [(set DSTREGCLASS:$dst, >>>>                (DSTTYPE (movlhps SRCREGCLASS:$src1, >>>>                                (DSTTYPE (bitconvert >>>>                                            (v2f64 (scalar_to_vector >>>>                                                      (loadf64 addr:$src2))))))))], >>>>        ...

On Sat, Jul 7, 2012 at 12:25 AM, Anthony Blake <amb33 at cs.waikato.ac.nz> wrote: > On Fri, Jul 6, 2012 at 6:39 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> On Jul 5, 2012, at 9:06 PM, Anthony Blake <amb33 at cs.waikato.ac.nz> wrote: >>> [...] >>> movaps 32(%rdi), %xmm3 >>> movaps 48(%rdi), %xmm2 >>>

On Fri, Jul 6, 2012 at 6:39 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Jul 5, 2012, at 9:06 PM, Anthony Blake <amb33 at cs.waikato.ac.nz> wrote: > >> I've noticed that LLVM tends to generate suboptimal code and spill an >> excessive amount of registers in large functions, such as in those >> that are automatically generated by FFTW. >

...ity to easily track down regressions. Thanks, Q. > > The amount of domain crossing is much lower now - but there are a number of float shuffles that now use double shuffles instead - fine from a domain point of view but rather unexpected. IIRC this often appeared in matrix transpose code - movlhps / movhlps being replaced by unpcklpd / unpckhpd is the one I seem to remember. > > Overall - a massive improvement - thank you! > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> ht...

This snippet of IR is interesting: %sub.ptr.div.iS37_D = sdiv <2 x i64> %sub.ptr.sub.iS36_D, <i64 24, i64 24> %cmp10S38_D = icmp ugt <2 x i64> %sub.ptr.div.iS37_D, %splatInsMapS1_D.splat %zextS39_D = sext <2 x i1> %cmp10S38_D to <2 x i64> %BCS39_D = bitcast <2 x i64> %zextS39_D to i128 %mskS39_D = icmp ne i128 %BCS39_D, 0 br i1 %mskS39_D,

...CK-LABEL: test14: >> -; CHECK: subps [[X1:%xmm[0-9]+]], [[X2:%xmm[0-9]+]] >> -; CHECK: addps [[X1]], [[X0:%xmm[0-9]+]] >> +; CHECK: addps [[X1:%xmm[0-9]+]], [[X0:%xmm[0-9]+]] >> +; CHECK: subps [[X1]], [[X2:%xmm[0-9]+]] >> ; CHECK: movlhps [[X2]], [[X0]] >> } >> >> @@ -221,4 +221,3 @@ entry: >> %double2float.i = fptrunc <4 x double> %0 to <4 x float> >> ret <4 x float> %double2float.i >> } >> - >> >> Modified: llvm/trunk/test/CodeGen/X86/store-narrow.ll >...