similar to: [LLVMdev] Types vs. register classes in instruction patterns -- effect on FastISel

On May 17, 2013, at 2:04 PM, Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote: > Hello, > > In http://llvm.org/viewvc/llvm-project?view=revision&revision=177889 and > http://llvm.org/viewvc/llvm-project?view=revision&revision=177890 (along > with some follow-up patches) the PowerPC back end was changed to use > types instead of register classes in instruction

On Fri, 2013-05-17 at 15:32 -0700, Jakob Stoklund Olesen wrote: > On May 17, 2013, at 2:04 PM, Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote: > > > Hello, > > > > In http://llvm.org/viewvc/llvm-project?view=revision&revision=177889 and > > http://llvm.org/viewvc/llvm-project?view=revision&revision=177890 (along > > with some follow-up

LLVM knows what all the types of the intrinsic functions are; I thought, why are users (including llvm-gcc...) required to duplicate all this information in order to use them? I mean in order to call getOrInsertFunction to get declarations for them. So I wrote this patch, which allows all this code to be generated automatically. Is this a good approach? Dan -- Dan Gohman, Cray Inc. <djg at

On Mon, 5 Feb 2007, Dan Gohman wrote: > LLVM knows what all the types of the intrinsic functions are; I thought, > why are users (including llvm-gcc...) required to duplicate all this > information in order to use them? I mean in order to call > getOrInsertFunction to get declarations for them. That is an excellent question! :) In the bad old days, we used to allow intrinsics

Hi there, I am a student considering a compiler design based dissertation with llvm. I am having problems building llvm on OpenBSD-current. I hope to make a port of llvm for OpenBSD once I have figured out how to build it. Observe: llvm[3]: Compiling Deserialize.cpp for Release build In file included from /home/edd/llvm/llvm-2.3/include/llvm/Bitcode/BitstreamRead er.h:18, from

Hello, Edd > > llvm[3]: Building ARM.td instruction selector implementation with tblgen > > assertion "getOperator()->isSubClassOf("SDNodeXForm") && "Unknown node > > type!"" failed: file "CodeGenDAGPatterns.cpp", line 949, function > > "ApplyTypeConstraints" Could you please try with gcc 4.x and check, whether

In IntrinsicEmitter::EmitTypeGenerate, called from IntrinsicEmitter::EmitGenerator, here for (unsigned j = 0; j != N; ++j) { OS << " ArgTys.push_back("; EmitTypeGenerate(OS, ParamTys[j], ArgNo); OS << ");\n"; } I'm hitting this assertion: if (ArgType->isSubClassOf("LLVMMatchType")) { unsigned Number =

On Thu, Jun 12, 2008 at 7:02 PM, Edd Barrett <vext01 at gmail.com> wrote: > gcc4.2 works fine. But it only works fine for svn snapshots. Your most recent release does not build on OpenBSD with gcc-4.2. llvm[3]: Building ARM.td instruction selector implementation with tblgen assertion "getOperator()->isSubClassOf("SDNodeXForm") && "Unknown node

On Mon, Feb 05, 2007 at 12:28:56PM -0800, Chris Lattner wrote: > On Mon, 5 Feb 2007, Dan Gohman wrote: > > > LLVM knows what all the types of the intrinsic functions are; I thought, > > why are users (including llvm-gcc...) required to duplicate all this > > information in order to use them? I mean in order to call > > getOrInsertFunction to get declarations for

That's a bug. I'm working on a fix.... On Apr 15, 2009, at 10:16 AM, Villmow, Micah wrote: > In IntrinsicEmitter::EmitTypeGenerate, called from > IntrinsicEmitter::EmitGenerator, here > for (unsigned j = 0; j != N; ++j) { > OS << " ArgTys.push_back("; > EmitTypeGenerate(OS, ParamTys[j], ArgNo); > OS << ");\n"; > }

On Thu, Jun 12, 2008 at 11:41 AM, Anton Korobeynikov <asl at math.spbu.ru> wrote: > Hello, Edd > >> > llvm[3]: Building ARM.td instruction selector implementation with tblgen >> > assertion "getOperator()->isSubClassOf("SDNodeXForm") && "Unknown node >> > type!"" failed: file "CodeGenDAGPatterns.cpp", line

On Wed, Jun 11, 2008 at 11:49 AM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > Could you please update to r52213 or later in svn and check whether > this error is resolved with your gcc? Latest trunk fixes that error. Next problem :) llvm[3]: Building ARM.td register information header with tblgen llvm[3]: Building ARM.td register names with tblgen llvm[3]: Building ARM.td

On Mon, Jun 16, 2008 at 05:00:24PM +0100, Edd Barrett wrote: > On Thu, Jun 12, 2008 at 7:02 PM, Edd Barrett <vext01 at gmail.com> wrote: > > gcc4.2 works fine. > > But it only works fine for svn snapshots. Your most recent release > does not build on OpenBSD with gcc-4.2. > > llvm[3]: Building ARM.td instruction selector implementation with tblgen > assertion

On Sep 23, 2011, at 1:38 PM, David A. Greene wrote: > Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > >> It appears that tablegen is inferring the 'type' of an individual >> register by enumerating all the register classes it appears in. Some >> things, like using implicit defs in SDNodes, only works for registers >> with a unique type. My

I have this intrinsic definition for llvm. def int_opencl_math_fdistance_fast : Intrinsic<[llvm_float_ty], [llvm_anyfloat_ty, LLVMMatchType<0>]>; Can someone explain what LLVMMatchType does and how to specify it to match the first argument and not the return value? I've tried LLVMMatchType<1> but it fails in IntrinsicEmitter.cpp

On Apr 15, 2009, at 9:29 AM, Villmow, Micah wrote: > I have this intrinsic definition for llvm. > def int_opencl_math_fdistance_fast : Intrinsic<[llvm_float_ty], > [llvm_anyfloat_ty, LLVMMatchType<0>]>; > > > Can someone explain what LLVMMatchType does and how to specify it > to match the first argument and not the return value?

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > It appears that tablegen is inferring the 'type' of an individual > register by enumerating all the register classes it appears in. Some > things, like using implicit defs in SDNodes, only works for registers > with a unique type. My WIDE32 class caused GR32 registers to no > longer have a unique type, breaking

On 2008-06-10, at 09:19, Edd Barrett wrote: > I am a student considering a compiler design based dissertation with > llvm. I am having problems building llvm on OpenBSD-current. I hope > to make a port of llvm for OpenBSD once I have figured out how to > build it. Hi Edd, Could you please update to r52213 or later in svn and check whether this error is resolved with your

So I tried adding a new register class to the x86 target: def WIDE32 : RegisterClass<"X86", [i32, f32], 32, (add GR32, FR32)>; I thought this would be a harmless thing to do since the new register class is not being referenced anywhere. I was wrong, it caused all kinds of assertion failures from tablegen's isel pattern generator. It appears that tablegen is inferring the

While building an OpenBSD port for LLVM 2.3 I encountered a few issues. The first one is that the system compiler $ gcc -v Reading specs from /usr/lib/gcc-lib/amd64-unknown-openbsd4.3/3.3.5/specs Configured with: Thread model: single gcc version 3.3.5 (propolice) Fails to build TableGen correctly which then crashes while processing the tables for ARM. I fixed this by using gcc 4.2.0 The