similar to: [LLVMdev] Hitting assertion, unsure why

Is there any known method/hack of bypassing this? Thanks, -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Bill Wendling Sent: Thursday, January 15, 2009 2:07 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Hitting assertion, unsure why On Thu, Jan 15, 2009 at 1:54 PM, Villmow, Micah <Micah.Villmow at amd.com>

On Thu, Jan 15, 2009 at 1:54 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > I am hitting this assertion: > > assert(I != VRBaseMap.end() && "Node emitted out of order - late"); > > I am not sure why this assertion is being triggered or what I changed that > is causing it. > > This is asserting when SDValue is FrameIndexSDNode 1. > > I

Don't generate debug info at this time (you can use "opt -strip-debug")? :-) Otherwise, I'm not sure. -bw On Thu, Jan 15, 2009 at 2:20 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Is there any known method/hack of bypassing this? > > Thanks, > > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at

This did not seem to work, any other ideas? Thanks, -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Bill Wendling Sent: Thursday, January 15, 2009 2:26 PM To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Hitting assertion, unsure why Don't generate debug info at this time (you can use "opt -strip-debug")?

Other than not using debugging ('-g' and the like), not really. :-( I think that Devang is actively working on fixing this, though. It might not be too much longer. -bw On Thu, Jan 15, 2009 at 3:26 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > This did not seem to work, any other ideas? > > Thanks, > > -----Original Message----- > From: llvmdev-bounces at

Ok, I've had time to track this down a little bit more and I seem to have found another case where it fails. This is occurring during Schedulur->EmitSchedule() in SelectionDAGISel.cpp:695. The problem seems to be that somehow the CopyToReg part of the switch statement in ScheduleDAG::EmitNode has a FrameIndex as its second operand. This is especially problematic because the code is either

On Jan 27, 2009, at 3:54 PM, Villmow, Micah wrote: > Ok, I've had time to track this down a little bit more and I seem to > have found another case where it fails. This is occurring during > Schedulur->EmitSchedule() in SelectionDAGISel.cpp:695. The problem > seems > to be that somehow the CopyToReg part of the switch statement in > ScheduleDAG::EmitNode has a

Well, I thought I knew how to fix the problem, but it seems my changes didn't help at all. The frame index is being created when FuncInfo->set() is called in SelectionDAGISel::runOnFunction(). This occurs at line 293 in SelectionDAGBuild.cpp when dealing with the alloca instructions. I've found the CopyToReg that is being issued occurs in LowerCALL and it is this one that fails. When I

I'm working on the code to handle GC tracing of "intermediate values" (as described in the GC doc), and I've run into a weird problem. (Note, this has nothing to do with the patch I have proposed, this error occurs with regular old pointer-allocas.) The exception I am getting occurs in this code here in SelectionDAGBuilder.cpp: *case* *Intrinsic*::gcroot: *if* (GFI) {

Hi, In SelectionDAGISel::SelectAllBasicBlocks if (TM.Options.EnableFastISel) FastIS = TLI->createFastISel(*FuncInfo, LibInfo); followed by if (!FastIS) { LowerArguments(Fn); } else { The above implies that implementing FastIS is optional. In contrast to that, testing whether FastIS is actually been used is done by testing if TM.Options.EnableFastISel is set. For example

Hi Mikaël, Thanks for the patch. Some comments: 1. Please don't use tabs. 2. Index: lib/Target/ARM/ARMInstrInfo.cpp =================================================================== --- lib/Target/ARM/ARMInstrInfo.cpp (revision 14) +++ lib/Target/ARM/ARMInstrInfo.cpp (working copy) @@ -904,7 +904,8 @@ return TAI->getInlineAsmLength(MI-

I'm trying to track down the problem with the assertion failure in SelectionDAGBuilder.cpp. This is the code: *case* *Intrinsic*::gcroot: *if* (GFI) { *const* Value *Alloca = I.getArgOperand(0); *const* Constant *TypeMap = cast<Constant>(I.getArgOperand(1)); * FrameIndexSDNode *FI = cast<FrameIndexSDNode>(getValue(Alloca).getNode());*

Hi Talin, I think that the framework for GC assumes llvm.gcroot to be in the first block. If it is not the case in your example, it will break these assumptions. Nicolas On Sun, Sep 26, 2010 at 1:38 AM, Talin <viridia at gmail.com> wrote: > I'm working on the code to handle GC tracing of "intermediate values" (as > described in the GC doc), and I've run into a

On Wed, Jun 26, 2019 at 12:38 PM Tim Northover <t.p.northover at gmail.com> wrote: > Hi Gleb, > > On Wed, 26 Jun 2019 at 07:28, Gleb Popov <6yearold at gmail.com> wrote: > > def StoreStackF : InstRI<2, (outs), (ins IntRegs:$reg, i32imm:$i), > > "storestackf $reg, [$i]", [(store_stack i32:$reg, > AddrFI:$i)]>; > > >

Drear there: The problem I have is to lower an intrinsic function like this ” float @llvm.write.arg(flaot %src, float* %dst) “ I am lowering it with INTRINSIC_W_CHAIN, so the return value and the value to write to dst are generated with some operations using src: " // it is the frame index node corresponding to input pointer SDvalue frindex = Op.getoperand(3); … SDValue returnValue =

Evan: What you requested was in the debug output (sans offending Node), but here it is, outside of the attachment. The offending node is highlighted: SU(0): 0xa908760: ch = EntryToken SU(1): 0xa907600: i32,ch,flag = CopyFromReg 0xa9095d0, 0xa9070e0, 0xa9095d0:1 0xa906e30: ch,flag = CopyToReg 0xa908760, 0xa9070e0, 0xa9071f0 <<--<<--<<--<<--<< Node

Hi Anton & Duncan, When I try to compile on Darwin now, I get this: $ /Volumes/Gir/devel/llvm/llvm-gcc-4.0.obj/gcc/xgcc <options> -o eh_alloc.o Assertion failed: (false && "Couldn't find the register class"), function getPhysicalRegisterRegClass, file /Volumes/Gir/devel/llvm/ llvm.src/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp, line 269.

Yup, I've got one remaining bug that holding up the CellSPU release. It still has a bunch of warts, but so long as I can get it into shape such that llvm-gcc-4.2 compiles all the way through, then we collectively have something with which to work. I'm getting the following error from llc, the attachments have llc's debug and the .ll files, respectively. Can anyone shed some

This is a scheduler assertion. It means a value (virtual register) use is somehow scheduled before its definition. Please run llc in gdb. Call dumpSchedule() to print out the schedule. Also please let me know which node it is processing at the time of the assertion. Evan On Oct 15, 2007, at 11:48 PM, Scott Michel <scottm at aero.org> wrote: > Yup, I've got one remaining bug

Sorry, still not enough information. I am guessing it's asserting in getVR() called from EmitNode()? The node is CopyToReg and it's trying to find the virtual register of operand 2? From the schedule, I don't see the definition of the operand. Can you do DAG.viewGraph()? That should gives us a better idea. Evan On Oct 16, 2007, at 9:06 PM, Scott Michel wrote: > Evan: >