search for: addsub

On Oct 17, 2011, at 3:40 PM, Hal Finkel wrote: > How should I go about matching floating-point addsub-like vector > instructions? My first inclination is to write something which matches > build_vector 1.0, -1.0, and then use that in combination with a match on > fadd, but that does not seem to work. I think this is because > BUILD_VECTOR cannot ever be "Legal", and so it is a...

How should I go about matching floating-point addsub-like vector instructions? My first inclination is to write something which matches build_vector 1.0, -1.0, and then use that in combination with a match on fadd, but that does not seem to work. I think this is because BUILD_VECTOR cannot ever be "Legal", and so it is always turned into a...

On Mon, 2011-10-17 at 17:33 -0700, Dan Gohman wrote: > On Oct 17, 2011, at 3:40 PM, Hal Finkel wrote: > > > How should I go about matching floating-point addsub-like vector > > instructions? My first inclination is to write something which matches > > build_vector 1.0, -1.0, and then use that in combination with a match on > > fadd, but that does not seem to work. I think this is because > > BUILD_VECTOR cannot ever be "Legal&q...

...0-18 at 10:51 -0700, Dan Gohman wrote: > On Oct 17, 2011, at 6:40 PM, Hal Finkel wrote: > > > On Mon, 2011-10-17 at 17:33 -0700, Dan Gohman wrote: > >> On Oct 17, 2011, at 3:40 PM, Hal Finkel wrote: > >> > >>> How should I go about matching floating-point addsub-like vector > >>> instructions? My first inclination is to write something which matches > >>> build_vector 1.0, -1.0, and then use that in combination with a match on > >>> fadd, but that does not seem to work. I think this is because > >>> BUILD_VEC...

On Oct 17, 2011, at 6:40 PM, Hal Finkel wrote: > On Mon, 2011-10-17 at 17:33 -0700, Dan Gohman wrote: >> On Oct 17, 2011, at 3:40 PM, Hal Finkel wrote: >> >>> How should I go about matching floating-point addsub-like vector >>> instructions? My first inclination is to write something which matches >>> build_vector 1.0, -1.0, and then use that in combination with a match on >>> fadd, but that does not seem to work. I think this is because >>> BUILD_VECTOR cannot ever be &...

...priate target instruction. This is how I handled x86 horizontal add (see the FHADD X86 opcode). If it turns out that the same thing is useful for other targets then it can be generalized later. Ciao, Duncan. On 10/18/11 00:40, Hal Finkel wrote: > How should I go about matching floating-point addsub-like vector > instructions? My first inclination is to write something which matches > build_vector 1.0, -1.0, and then use that in combination with a match on > fadd, but that does not seem to work. I think this is because > BUILD_VECTOR cannot ever be "Legal", and so it is a...

...t; code generator than as an intrinsic. > Need for variable arguments is that we don't know beforehand which custom operations we support. So practically we just give operation name and 1 or more parameters depending how many parameters custom operation has. e.g. __custom_operation("addsub", a, b, c) In lowering of intrinsic function we check from the processor, which type of parameters our current processor has for operation named "addsub" and write corresponding native code. >> Is there need to make changes to llvm-gcc for supporting new GCCBuiltin >> t...

Hi Renato, > I was recently investigating the build bot infrastructure and noticed > that the arm-linux target is failing for quite a long time. I believe > that it means ARM code is not executed all that often in LLVM tests, > is that correct? > > We were wondering what kind of support we could give to make sure ARM > code is correct and don't regress, specially before

...failed 2009-03-17-lsr-apint.ll <http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/760/steps/test-llvm/logs/2009-03-17-lsr-apint.ll> add-with-overflow-128.ll <http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/760/steps/test-llvm/logs/add-with-overflow-128.ll> i128-addsub.ll <http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/760/steps/test-llvm/logs/i128-addsub.ll> ... 761 - 769 - dito http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/770 - Revision: 129068 failed build http://google1.osuosl.org:8011/builders/llvm-arm-linux/builds/771...

Hi all, I was recently investigating the build bot infrastructure and noticed that the arm-linux target is failing for quite a long time. I believe that it means ARM code is not executed all that often in LLVM tests, is that correct? We were wondering what kind of support we could give to make sure ARM code is correct and don't regress, specially before releases (I know it's a bit late

On Wed, 1 Aug 2007, [UTF-8] Mikael Lepist? wrote: >> def MOVNTPSmr : PSI<0x2B, MRMDestMem, (outs), (ins i128mem:$dst, >> VR128:$src), >> "movntps {$src, $dst|$dst, $src}", >> [(int_x86_sse_movnt_ps addr:$dst, VR128:$src)]>; >> >> There is corresponding code in llvm-gcc to tell GCC how to handle this >> builtin. Is this what you're

Chris Lattner wrote: > On Tue, 31 Jul 2007, [ISO-8859-1] Mikael Lepist� wrote: >> I was talking with aKor in #llvm how we could implement custom operation >> support for our ASIP architecture. We came into solution that the best >> way would be to write new custom operation intrinsic and optimization >> pass for raising certain type of function calls to those intrinsics

...rcel/LLVM/src/llvm/test/CodeGen/Generic/ > 2007-04-27-LargeMemObject.ll for PR1557 Likewise. > FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/ > 2008-02-20-MatchingMem.ll for PR1133 Likewise. > FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/i128- > addsub.ll > Failed with signal(SIGABRT) at line 1 > while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/ > CodeGen/Generic/i128-addsub.ll | llc > > .ident "LLVM-ia64" > > .psr lsb > .radix C > .psr abi64 > Cannot yet select: 0x2000000001d7...

I have two patterns in tablegen that do look like the exact same thing: Pat 1) def MOV_v4i16 : ILFormat<IL_OP_MOV, (outs GPRV4I16:$dst), (ins i16imm:$val), asm, [(set GPRV4I16:$dst, (build_vector (i16 imm:$val)))]>; Pat 2) def v4i16imm : Operand<v4i16>; def MOV_v4i16 : ILFormat<IL_OP_MOV, (outs GPRV4I16:$dst), (ins v4i16imm:$val), asm, [(set

....ident "LLVM-ia64" .psr lsb .radix C .psr abi64 XXX: getRegForInlineAsmConstraint XXX: getRegForInlineAsmConstraint XXX: getRegClassForInlineAsmConstraint Could not match memory address. Inline asm failure! FAIL: /dumpster/home/marcel/LLVM/src/llvm/test/CodeGen/Generic/i128- addsub.ll Failed with signal(SIGABRT) at line 1 while running: llvm-as < /dumpster/home/marcel/LLVM/src/llvm/test/ CodeGen/Generic/i128-addsub.ll | llc .ident "LLVM-ia64" .psr lsb .radix C .psr abi64 Cannot yet select: 0x2000000001d78120: i64,flag = adde 0x2000000001d3c520, 0x2...

Hi, I'm working on a project to generate native code for a domain specific langauge where the user defines functions in the complex plane. This implies that I need to support complex numbers as a datatype with LLVM. Its fairly straightforward to create a struct of two floats (or doubles, etc.) and do the simple operations like add, subtract, multiply, divide, etc. However, things get

On May 24, 2008, at 11:43 AM, Marcel Moolenaar wrote: > All, > > So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD > and aside for ia64, things look pretty good for a first try. There > are 2 unexpected failures for PowerPC, which appear to be caused by > uninitialized memory. I'm still working on a fix for that (need to > brush up on my C++

All, So far I've tried LLVM on amd64, i386, ia64 and powerpc under FreeBSD and aside for ia64, things look pretty good for a first try. There are 2 unexpected failures for PowerPC, which appear to be caused by uninitialized memory. I'm still working on a fix for that (need to brush up on my C++ skills). [sidenote: In FreeBSD -current, the memory allocator initializes memory with 0xa5

...d cases?). > > > > > > > > Also, support needs to be added for fusing known intrinsics (fma, > > > > etc.), > > > > and, as has been discussed on llvmdev, we should add some > > > > intrinsics to > > > > allow the generation of addsub-type instructions. > > > > > > > > I've included a few tests, but it needs more. Please review (I'll > > > > commit > > > > if and when everyone is happy). > > > > > > > > Thanks in advance, > > > > Hal >...

...> > > > > > Also, support needs to be added for fusing known intrinsics (fma, > > > > > etc.), > > > > > and, as has been discussed on llvmdev, we should add some > > > > > intrinsics to > > > > > allow the generation of addsub-type instructions. > > > > > > > > > > I've included a few tests, but it needs more. Please review (I'll > > > > > commit > > > > > if and when everyone is happy). > > > > > > > > > > Thanks in advance...