On Jul 16, 2009, at 10:04 AM, Aaron Gray wrote:> > I understand that you say that, but I can't bring myself to care at > this point. Have you thought about how many cycles are already used > to produce the instructions that lead to the emission of those 10K > bytes? The total percentage of time spent doing these virtual calls > will be tiny compared to the total time to generate the code. > > If you switch to using virtual functions, get the code working, and > we *measure* a performance problem, then we can fix it. There are > much better ways to do this than templating the whole code emitter. > > That means JIT code also has the virtual function overhead too, this > will slow down existing JIT code. Templates are already there and > they work and they do not take up _too_ much memory.As I said before, if you are compelled to, feel free to continue with your approach of premature optimization. I will fix it later. -Chris
2009/7/16 Chris Lattner <clattner at apple.com>> > On Jul 16, 2009, at 10:04 AM, Aaron Gray wrote: > > >> I understand that you say that, but I can't bring myself to care at this >> point. Have you thought about how many cycles are already used to produce >> the instructions that lead to the emission of those 10K bytes? The total >> percentage of time spent doing these virtual calls will be tiny compared to >> the total time to generate the code. >> >> If you switch to using virtual functions, get the code working, and we >> *measure* a performance problem, then we can fix it. There are much better >> ways to do this than templating the whole code emitter. >> >> That means JIT code also has the virtual function overhead too, this will >> slow down existing JIT code. Templates are already there and they work and >> they do not take up _too_ much memory. >> > > As I said before, if you are compelled to, feel free to continue with your > approach of premature optimization. I will fix it later.If you are not too bothered with the memory overhead in the short term then it is probably best to leave the code as it is for meantime. I think the original MachineCodeEmitter with inline emit* functions and for virtual functions like extend() so we can control memory management in sub classes. class MachineCodeEmitter { public: .... inline void emitByte( uint8_t b) { if (freespace()) BufferPtr++ = b; else { extend(); BufferPtr++ = b; } } protected: void virtual extend() = 0 }; so extend is overriden in JITCodeEmitter and ObjectCodeEmitter and is called moving emitted code to a bigger buffer if we run out of memory, then emission continues. This gives the lowest overhead and flexability. If ObjectCodeEmitter and JITEmitter manage memory then the design is transparent to the higher levels of DOE and JIT. The old design was the best design it just needed an extend() method. Aaron> > -Chris >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090716/e83b246b/attachment.html>
2009/7/16 Aaron Gray <aaronngray.lists at googlemail.com>> 2009/7/16 Chris Lattner <clattner at apple.com> > >> >> On Jul 16, 2009, at 10:04 AM, Aaron Gray wrote: >> >> >>> I understand that you say that, but I can't bring myself to care at this >>> point. Have you thought about how many cycles are already used to produce >>> the instructions that lead to the emission of those 10K bytes? The total >>> percentage of time spent doing these virtual calls will be tiny compared to >>> the total time to generate the code. >>> >>> If you switch to using virtual functions, get the code working, and we >>> *measure* a performance problem, then we can fix it. There are much better >>> ways to do this than templating the whole code emitter. >>> >>> That means JIT code also has the virtual function overhead too, this will >>> slow down existing JIT code. Templates are already there and they work and >>> they do not take up _too_ much memory. >>> >> >> As I said before, if you are compelled to, feel free to continue with >> your approach of premature optimization. I will fix it later. >> > > If you are not too bothered with the memory overhead in the short term then > it is probably best to leave the code as it is for meantime. > > I think the original MachineCodeEmitter with inline emit* functions and for > virtual functions like extend() so we can control memory management in sub > classes. > > class MachineCodeEmitter { > public: > .... > inline void emitByte( uint8_t b) { > if (freespace()) > BufferPtr++ = b; > else { > extend(); > BufferPtr++ = b; > } > } > > protected: > void virtual extend() = 0 > }; > > so extend is overriden in JITCodeEmitter and ObjectCodeEmitter and is > called moving emitted code to a bigger buffer if we run out of memory, then > emission continues. > > This gives the lowest overhead and flexability. If ObjectCodeEmitter and > JITEmitter manage memory then the design is transparent to the higher levels > of DOE and JIT. > > The old design was the best design it just needed an extend() method. >Oh, and JITEmitter::finishFunction will have to provide relocations for JIT too. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090716/6777a05a/attachment.html>