On Monday 13 July 2009 13:13, Chris Lattner wrote:> > We're not going to submit our line number stuff anyway (it's too > > much of a > > hack) but we would like the comment infrastructure to be there. > > DebugLoc is there. The transition isn't complete at the LLVM IR > level, but it is at the MachineInstr level AFAIK.Well, the IR level is pretty important to us since we convert our code into LLVM IR and add source line comments at the same time.> Vector vs scalar should also be pretty simple, just look at the reg > class and the VT's involved. It should all be target independent, > probably less than a dozen lines. After the conversion to > formatted_raw_ostream, we can discuss the best way to do this. It > would be helpful if you gave an example of the output you wanted.Ok, this might work.> I don't know what you mean by "pattern information". We can obviously > enhance tblgen to include any information that we need, but I don't > see how the asmprinter wouldn't know something that an earlier pass > would. Again, it would be helpful if you included example output to > show what you're going for.Ok, here's an example: movl (%rsi), %ecx # LLVM Instruction: volatile store i32* %ksize, i32** %ksize3 ; [oox.4 : sln.5] # [result] Pattern 1367 I then hacked tblgen to output this in the generated isel file: // Pattern 1367: (ld:i32 addr:iPTR:$src)<<P:Predicate_load>> // Emits: (MOV32rm:i32 addr:iPTR:$src) PatternID = 1367; // Pattern complexity = 19 cost = 1 size = 3 SDValue CPTmp01; SDValue CPTmp11; SDValue CPTmp21; SDValue CPTmp31; if (SelectAddr(N, N1, CPTmp01, CPTmp11, CPTmp21, CPTmp31)) { CurDAG->setSubgraphColor(N.getNode(), "red"); SDNode *Result = Emit_125(N, X86::MOV32rm, MVT::i32, CPTmp01, CPTmp11, CPTmp21, CPTmp31, PatternID); if(Result) { CurDAG->setSubgraphColor(Result, "yellow"); CurDAG->setSubgraphColor(Result, "black"); } return Result; } } So it's really easy to set a breakpoint in Emit_125 to look for the pattern number in question. I forgot about the LLVM instruction information. That's something that can't be synthesized by the asmprinter. Again, we only emit some of this with special debug flags so we don't carry the original IR around in comments all the time. :)> > What's the plan for meta-information? Could comments go there when > > it's > > ready? Would it be ok to add these for now and remove them as other > > mechanisms (DebugLoc, meta-information) come on-line? > > Which meta-information, MDNode and friends?I don't know, I've just heard the term from time to time. Sounds like it's not appropriate for this, though. -Dave
On Monday 13 July 2009 13:29, David Greene wrote:> I forgot about the LLVM instruction information. That's something that > can't be synthesized by the asmprinter. Again, we only emit some of this > with special debug flags so we don't carry the original IR around in > comments all the time. :)If the FI question can be answered (how do we know it's a spill slot)? Then the above is the only use I think we don't have a long-term answer for. I don't see how asmprinter can synthesize this information. Line numbers are still a problem because we need to propagate the information from LLVM IR to MachineInstrs and there's currently no DebugLoc information in LLVM IR Instructions. I'll take a look at the existing DebugLoc and see if we can put our LLVM IR line number info there instead of printing it to comments early. If it's any comfort, we've been running with this MachineInstr for a very long time and done multiple public releases. We always go through asm to do our x86 compiles and no one has ever complained about compile time or memory usage in this area (legalize is actually our biggest problem). And we compile HUGE source files containing very large functions. Of course, our requirements aren't the same as everyone else's requirements so I understand that there may be tighter tolerances in some use cases. Examples of where the MachineInstr comments might be a problem would be helpful. -Dave
On Jul 13, 2009, at 11:29 AM, David Greene wrote:> On Monday 13 July 2009 13:13, Chris Lattner wrote: > >>> We're not going to submit our line number stuff anyway (it's too >>> much of a >>> hack) but we would like the comment infrastructure to be there. >> >> DebugLoc is there. The transition isn't complete at the LLVM IR >> level, but it is at the MachineInstr level AFAIK. > > Well, the IR level is pretty important to us since we convert our > code into LLVM IR and add source line comments at the same time.Well sure, but how is that relevant? Just generate llvm.stoppoint and isel turns them into debug locs. Just because debugloc isn't on llvm::Instruction doesn't mean you don't get line numbers :).>> I don't know what you mean by "pattern information". We can >> obviously >> enhance tblgen to include any information that we need, but I don't >> see how the asmprinter wouldn't know something that an earlier pass >> would. Again, it would be helpful if you included example output to >> show what you're going for. > > Ok, here's an example: > > movl (%rsi), %ecx # LLVM > Instruction: volatile store i32* %ksize, i32** %ksize3 ; > [oox.4 : sln.5] > > # > [result] Pattern > 1367Instead of printing 1367, why not print "MOV32rm" like -print- machineinstr does? If you really want 1367, just print MI- >getOpcode(). The asmprinter definitely has this information.> I forgot about the LLVM instruction information. That's something > that can't > be synthesized by the asmprinter. Again, we only emit some of this > with > special debug flags so we don't carry the original IR around in > comments all > the time. :)Sure, I understand that comments in general only get turned on with something like -fverbose-asm. But where/how do you expect this information to be propagated onto the machineinstrs? For now, lets go forward with the plan of having the asmprinter generate the comments. It sounds like it can cover at least 75% of what you're interested in, and the other cases probably have better solutions that sticking a vector of std::string on MachineInstr. -Chris
On Jul 13, 2009, at 1:34 PM, David Greene wrote:> On Monday 13 July 2009 13:29, David Greene wrote: > >> I forgot about the LLVM instruction information. That's something >> that >> can't be synthesized by the asmprinter. Again, we only emit some >> of this >> with special debug flags so we don't carry the original IR around in >> comments all the time. :) > > If the FI question can be answered (how do we know it's a spill slot)?I just responded separately.> Then the above is the only use I think we don't have a long-term > answer for. > I don't see how asmprinter can synthesize this information.I agree, but our isel currently doesn't propagate this in any other way either. Lets just defer this issue for now.> Line numbers are still a problem because we need to propagate the > information > from LLVM IR to MachineInstrs and there's currently no DebugLoc > information > in LLVM IR Instructions. I'll take a look at the existing DebugLoc > and see if > we can put our LLVM IR line number info there instead of printing it > to > comments early.Just generate stoppoints like llvm-gcc.> If it's any comfort, we've been running with this MachineInstr for a > very long time and done multiple public releases. We always go > through > asm to do our x86 compiles and no one has ever complained about > compile > time or memory usage in this area (legalize is actually our biggest > problem). > And we compile HUGE source files containing very large functions.We care most about -O0 compile times, which generally don't use legalize or selection dags at all, and use the local register allocator. -Chris
On Monday 13 July 2009 15:46, Chris Lattner wrote:> Well sure, but how is that relevant? Just generate llvm.stoppoint and > isel turns them into debug locs. Just because debugloc isn't on > llvm::Instruction doesn't mean you don't get line numbers :).You're right, it's not a big hurdle.> > Ok, here's an example: > > > > movl (%rsi), %ecx # LLVM > > Instruction: volatile store i32* %ksize, i32** %ksize3 ; > > [oox.4 : sln.5] > > > > # > > [result] Pattern > > 1367 > > Instead of printing 1367, why not print "MOV32rm" like -print- > machineinstr does? If you really want 1367, just print MI- > > >getOpcode(). The asmprinter definitely has this information.Ok, I wasn't aware of that at the time I did this stuff. Printing the pattern name is even better!> > I forgot about the LLVM instruction information. That's something > > that can't > > be synthesized by the asmprinter. Again, we only emit some of this > > with > > special debug flags so we don't carry the original IR around in > > comments all > > the time. :) > > Sure, I understand that comments in general only get turned on with > something like -fverbose-asm. But where/how do you expect this > information to be propagated onto the machineinstrs?Some comments are on all the time, but those I think we can do with asmprinter, as you suggest. I have patches that propagate comments from Instructions to SDNodes to MachineInstrs. Again, after answering the FI stack slot question, the IR-level instruction information is the only thing we can't do through asmprinter. I'm open to other ways of capturing the information that don't require comments in MachineInstrs. But the information has to be stored somewhere. This IR instruction stuff isn't a huge priority for us. It's helpful when debugging but the TableGen information is way more important. I wouldn't cry too much if we can't get the IR instruction information in right now.> For now, lets go forward with the plan of having the asmprinter > generate the comments. It sounds like it can cover at least 75% of > what you're interested in, and the other cases probably have better > solutions that sticking a vector of std::string on MachineInstr.That's ok by me. Let's hash through this some more as stuff comes on-line. -Dave
David Greene wrote:> On Monday 13 July 2009 13:29, David Greene wrote: > >> I forgot about the LLVM instruction information. That's something that >> can't be synthesized by the asmprinter. Again, we only emit some of this >> with special debug flags so we don't carry the original IR around in >> comments all the time. :) > > If the FI question can be answered (how do we know it's a spill slot)? > Then the above is the only use I think we don't have a long-term answer for. > I don't see how asmprinter can synthesize this information. > > Line numbers are still a problem because we need to propagate the information > from LLVM IR to MachineInstrs and there's currently no DebugLoc information > in LLVM IR Instructions. I'll take a look at the existing DebugLoc and see if > we can put our LLVM IR line number info there instead of printing it to > comments early. > > If it's any comfort, we've been running with this MachineInstr for a > very long time and done multiple public releases. We always go through > asm to do our x86 compiles and no one has ever complained about compile > time or memory usage in this area (legalize is actually our biggest problem). > And we compile HUGE source files containing very large functions. > > Of course, our requirements aren't the same as everyone else's requirements > so I understand that there may be tighter tolerances in some use cases. > Examples of where the MachineInstr comments might be a problem would be > helpful. >In JIT compilers anything that slows down compilation is BAD. Plus most VMs already have there own debug/introspection infrastructure, so none is required in the machine code. Also when translating from a very high level language to llvm, there tends to be a *lot* of instructions, so keeping them small is important. I have posted in the past lamenting llvm slow compilation and it has got faster since. So, thanks to everyone for making the machine-code generation faster, and please, keep making it faster :)> -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >