Displaying 20 results from an estimated 200 matches similar to: "[LLVMdev] Types vs. register classes in instruction patterns -- effect on FastISel"
2013 May 17
0
[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
2013 May 19
1
[LLVMdev] Types vs. register classes in instruction patterns -- effect on FastISel
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
2007 Feb 05
2
[LLVMdev] automatically generating intrinsic declarations
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
2007 Feb 05
0
[LLVMdev] automatically generating intrinsic declarations
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
2008 Jun 10
6
[LLVMdev] LLVM on OpenBSD
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
2008 Jun 12
1
[LLVMdev] LLVM on OpenBSD
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
2009 Apr 15
3
[LLVMdev] Tablegen question
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 =
2008 Jun 16
2
[LLVMdev] LLVM on OpenBSD
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
2007 Feb 06
1
[LLVMdev] automatically generating intrinsic declarations
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
2009 Apr 15
0
[LLVMdev] Tablegen question
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";
> }
2008 Jun 12
0
[LLVMdev] LLVM on OpenBSD
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
2008 Jun 11
1
[LLVMdev] LLVM on OpenBSD
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
2008 Jun 16
0
[LLVMdev] LLVM on OpenBSD
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
2011 Sep 23
2
[LLVMdev] Registers and isel type inference
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
2009 Apr 15
2
[LLVMdev] Tablegen question
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
2009 Apr 15
0
[LLVMdev] Tablegen question
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?
2011 Sep 23
0
[LLVMdev] Registers and isel type inference
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
2008 Jun 11
0
[LLVMdev] LLVM on OpenBSD
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
2011 Sep 23
2
[LLVMdev] Registers and isel type inference
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
2008 Sep 21
2
[LLVMdev] OpenBSD port in progress
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