search for: x86instr64bit

Hello, This bug affects all LLVM versions from 2.6 to trunk : http://llvm.org/bugs/show_bug.cgi?id=5081 The workaround I found is to add this : Index: lib/Target/X86/X86Instr64bit.td =================================================================== --- lib/Target/X86/X86Instr64bit.td (revision 105882) +++ lib/Target/X86/X86Instr64bit.td (working copy) @@ -1832,6 +1832,8 @@ (MOV64ri64i32 tjumptable :$dst)>, Requires<[SmallCode]>; def : Pat&lt...

On Jun 21, 2010, at 2:56 AM, Patrick Marlier wrote: > Hello, > > This bug affects all LLVM versions from 2.6 to trunk : > http://llvm.org/bugs/show_bug.cgi?id=5081 > > The workaround I found is to add this : > > Index: lib/Target/X86/X86Instr64bit.td > =================================================================== > --- lib/Target/X86/X86Instr64bit.td (revision 105882) > +++ lib/Target/X86/X86Instr64bit.td (working copy) > @@ -1832,6 +1832,8 @@ > (MOV64ri64i32 tjumptable :$dst)>, Requires<[SmallC...

...un 21, 2010, at 2:56 AM, Patrick Marlier wrote: > > >> Hello, >> >> This bug affects all LLVM versions from 2.6 to trunk : >> http://llvm.org/bugs/show_bug.cgi?id=5081 >> >> The workaround I found is to add this : >> >> Index: lib/Target/X86/X86Instr64bit.td >> =================================================================== >> --- lib/Target/X86/X86Instr64bit.td (revision 105882) >> +++ lib/Target/X86/X86Instr64bit.td (working copy) >> @@ -1832,6 +1832,8 @@ >> (MOV64ri64i32 tjumptable :$dst)>...

...: >> >> >>> Hello, >>> >>> This bug affects all LLVM versions from 2.6 to trunk : >>> http://llvm.org/bugs/show_bug.cgi?id=5081 >>> >>> The workaround I found is to add this : >>> >>> Index: lib/Target/X86/X86Instr64bit.td >>> =================================================================== >>> --- lib/Target/X86/X86Instr64bit.td (revision 105882) >>> +++ lib/Target/X86/X86Instr64bit.td (working copy) >>> @@ -1832,6 +1832,8 @@ >>> (MOV64ri64...

Hi Eli, I have tried this, but the resulting tool-chain was broken. There are only two references to "CALL64m": the definition in X86Instr64bit.td, and an entry in X86InstrInfo.cpp. After commenting both out, compilation of a large application fails with: llc: ScheduleDAG.cpp:462: void llvm::ScheduleDAGTopologicalSort::InitDAGTopologicalSorting(): Assertion `Node2Index[SU->NodeNum] > Node2Index[I->getSUnit()->NodeNum] &&am...

Is there a way to define a multi-class pattern in tablegen? Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. S1-609 One AMD Place Sunnyvale, CA. 94085 P: 408-749-3966 -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Mon, Feb 9, 2009 at 5:17 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Is there a way to define a multi-class pattern in tablegen? > Yes. See "multiclass" and "defm" in, say, X86Instr64bit.td, et al. -bw

...Have there been any changes to the x86-64 backend of the JIT which might > break tail call elimination? I didn't see any announcements about major > changes in the JIT on the ml, so I have no idea what might be going > wrong there. I haven't tested it, but the following pattern in X86Instr64bit.td looks suspicious as it appears to attempt to support direct tailcalls to arbitrary 64-bit immediates: def : Pat<(X86tcret GR64:$dst, imm:$off), (TCRETURNri64 GR64:$dst, imm:$off)>; Dan

...at tpoff, %al are all illegal. So we appear to be lowering something, and trying to make an illegal move out of it. Unfortunately we're really short on testcases here. :) I've made an attempt that works for the current test and passes our set of tests in: Sending lib/Target/X86/X86Instr64bit.td Sending test/CodeGen/X86/x86-64-tls-1.ll Transmitting file data .. Committed revision 107860. Going to need some more testcases soon though if you run into any more problems :) -eric

On Tue, Jun 8, 2010 at 4:20 PM, David Meyer <pdox at google.com> wrote: > Hi Eli, > I have tried this, but the resulting tool-chain was broken. > There are only two references to "CALL64m": the definition in > X86Instr64bit.td, and an entry in X86InstrInfo.cpp. > After commenting both out, compilation of a large application fails with: > llc: ScheduleDAG.cpp:462: void > llvm::ScheduleDAGTopologicalSort::InitDAGTopologicalSorting(): Assertion > `Node2Index[SU->NodeNum] > Node2Index[I->getSUnit()-&g...

...li.friedman at gmail.com> wrote: > On Tue, Jun 8, 2010 at 4:20 PM, David Meyer <pdox at google.com> wrote: > > Hi Eli, > > I have tried this, but the resulting tool-chain was broken. > > There are only two references to "CALL64m": the definition in > > X86Instr64bit.td, and an entry in X86InstrInfo.cpp. > > After commenting both out, compilation of a large application fails with: > > llc: ScheduleDAG.cpp:462: void > > llvm::ScheduleDAGTopologicalSort::InitDAGTopologicalSorting(): Assertion > > `Node2Index[SU->NodeNum] > Node2Index...

On Jul 7, 2010, at 4:52 AM, Patrick Marlier wrote: > Which one is correct ? > - movl $tm_nest_level at TPOFF, %ecx > or > - movq $tm_nest_level at TPOFF, %rcx > or > - movl tm_nest_level at TPOFF, %ecx > I believe this is initial exec and so from: http://people.redhat.com/drepper/tls.pdf it would be movl tm_nest_level at TPOFF, %ecx > Otherwise, Is there a

Jon Harrop wrote: > I've come up with the following minimal repro that segfaults on my machine: Jon, were you able to resolve this? FWIW, TOT is causing all kinds of weird segfaults related to tail calls in my Pure interpreter, too (at least on x86-64). In my case these seem to be limited to the JIT, however (batch-compiled Pure programs via opt+llc all work fine, even with TCO), so

Ok, I am tracking down some bugs in our AVX stuff and came upon an interesting conundrum. The MOVQ instruction (MOVPQIto64rr in X86Instr64bit.td) only takes xmm registers. There is no ymm version since the xxm's are subregisters. I need to be able to match a vector element extract of element 0 on a v4i64 vector. Obviously this is not a legal operation even with AVX because MOVQ only operates on xmms. So I can mark it as not legal...

Hi, I am attempting to modify LLVM to generate code for an architecture which is nearly identical to X86-64, but with a few minor differences. In particular, "call" must always have a register operand, and cannot have a memory operand. Any ideas on how I can express this rule? Thanks, - David -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Tue, Jun 8, 2010 at 2:05 PM, David Meyer <pdox at google.com> wrote: > Hi, > I am attempting to modify LLVM to generate code for an architecture which is > nearly identical to X86-64, but with a few minor differences. > In particular, "call" must always have a register operand, and cannot have a > memory operand. Any ideas on how I can express this rule? Just get

Thanks, I seem to have gotten sub-registers to work. I can't seem to suppress the zero-extend sometimes. There is no need to explicitly zero extend bytes to words on this machine as all byte operations do that. I have also gotten some memory-to-memory to work. Bagel Evan Cheng wrote: > On Mar 14, 2008, at 10:17 AM, Bagel wrote: > >> I'm trying to write a backend for a

...PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Multiclass patterns On Mon, Feb 9, 2009 at 5:17 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Is there a way to define a multi-class pattern in tablegen? > Yes. See "multiclass" and "defm" in, say, X86Instr64bit.td, et al. -bw _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev