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 >
On Tuesday 14 July 2009 04:52, Mark Shannon wrote:> 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.JITs don't generate asm.> 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.Indeed. We've encountered very large functions here with no problem. -Dave
On Jul 14, 2009, at 12:19 PM, David Greene wrote:> On Tuesday 14 July 2009 04:52, Mark Shannon wrote: >> 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. > > JITs don't generate asm.JITs do use MachineInstr though, so making them large or more expensive impacts a JIT. -Chris
Mark Shannon
2009-Jul-15 09:32 UTC
[LLVMdev] [PATCH] Support asm comment output[MESSAGE NOT SCANNED]
David Greene wrote:> On Tuesday 14 July 2009 04:52, Mark Shannon wrote: >> 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. > > JITs don't generate asm.Indeed yes. But the JIT does still take the IR, and if that takes longer to create and process, then it is bad. Obviously the ideal is some sort of annotations that have practically zero cost if they are not used.> >> 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. > > Indeed. We've encountered very large functions here with no problem. > > -Dave > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >