search for: emitt

...2016, at 3:17 PM, Peter Collingbourne via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > Hi all, > > > > We have profiled [1] the memory usage in LLVM when LTO'ing Chromium, and > > we've found that one of the top consumers of memory is the DWARF emitter in > > lib/CodeGen/AsmPrinter/Dwarf*. > > I'm staring at the profile attached to the post #15 on the link you posted, can you confirm that the Dwarf emitter accounts for 6.7%+15.6%=22.3% of the the total allocated memory? > If I understand correctly the numbers, this does not...

...ible during the scheduling process. I did write a class that generates a complete binary encoding from a MachineInstruction, which took a while to do, but then I thought what if I needed to target other processors such as ARM, then I’ll have to do the same thing all over again knowing that the code emitter could get the job done. Isn’t that the job of the code emitter converting the MachineInstruction to machine code through the tableGen which has the definition of each instruction. Isn’t it possible to just activate the code emitter during Post-RA scheduler. Sorry for the trouble! Thanks, Ja...

Hi there, I think I've found a bug in the x86 JIT. I get an assertion failure when using thread-local variables and the fast emitter. It only happens with the JIT, the fast emiiter and thread-locals. (The IR passes the verifier) Here's the failure: X86CodeEmitter.cpp:516: void<unnamed>::Emitter::emitInstruction(const llvm::MachineInstr&, const llvm::TargetInstrDesc*): Assertion `0 && "psuedo inst...

...ible during the scheduling process. I did write a class that generates a complete binary encoding from a MachineInstruction, which took a while to do, but then I thought what if I needed to target other processors such as ARM, then I’ll have to do the same thing all over again knowing that the code emitter could get the job done. Isn’t that the job of the code emitter converting the MachineInstruction to machine code through the tableGen which has the definition of each instruction. Isn’t it possible to just activate the code emitter during Post-RA scheduler. > No. Two reasons that’s not goin...

...Instr::getOpcode() for a register operand returns an enum value that doesn’t represent the actual physical numbering of the register, to know what register this returned value represents I should refer to MipsGenRegisterInfo.td, that’s where I think the mapping happens. However, inside the MipsCodeEmitter class there is a method that returns the binary encoding of the machine instruction (uint64_t MipsCodeEmitter::getBinaryCodeForInstr(const MachineInstr &MI)). That’s why I thought about activating the code emitter during post-ra would solve my problem if that’s even possible. Thanks, - J...

...t; > llvm-dev at lists.llvm.org> wrote: > >>> > >>> Hi all, > >>> > >>> We have profiled [1] the memory usage in LLVM when LTO'ing Chromium, > and > >>> we've found that one of the top consumers of memory is the DWARF > emitter in > >>> lib/CodeGen/AsmPrinter/Dwarf*. > >> > >> I'm staring at the profile attached to the post #15 on the link you > posted, can you confirm that the Dwarf emitter accounts for > 6.7%+15.6%=22.3% of the the total allocated memory? > >> If I unde...

...pcode() for a register operand returns an enum value that doesn’t represent the actual physical numbering of the register, to know what register this returned value represents I should refer to MipsGenRegisterInfo.td, that’s where I think the mapping happens. > > However, inside the MipsCodeEmitter class there is a method that returns the binary encoding of the machine instruction (uint64_t MipsCodeEmitter::getBinaryCodeForInstr(const MachineInstr &MI)). That’s why I thought about activating the code emitter during post-ra would solve my problem if that’s even possible. > > Than...

Hi all, when trying to build LLVM+Clang (r180247) on a BlueGene/Q, I get the following error message (multiple times): llvm[3]: Building PPC.td code emitter with tblgen llvm-tblgen: Unknown command line argument '-gen-emitter'. Try: '/homea/jjsc13/jjsc1301/.pool/.build/llvm_r180241/Release+Asserts/bin/llvm-tblgen -help' llvm-tblgen: Did you mean '-mc-emitter'? Has anyone encountered this yet? When I actually run the suggeste...

I need to represent each instruction with its (32-bit) binary encoding, and I reached to a conclusion that I could get the encoding through the MipsCodeEmitter. What I’m trying to do exactly is write a scheduler which tries to minimize the switching activity between the scheduled instructions in each basic block. One way to do that is by representing each instruction with its complete binary encoding, which will be available after the register allocatio...

Thanks, that helps. The code emitter is definitely not the way you want to go about solving this problem, though. Are the instruction opcode (MachineInstr::getOpcode()) and the operand values not sufficient? All the information present in the encoding should be inferable from those, as that’s where the encoding comes from. -Jim...

X86 JIT does not yet support TLS. Evan On Jun 12, 2009, at 2:48 AM, Mark Shannon wrote: > Hi there, > > I think I've found a bug in the x86 JIT. I get an assertion failure > when > using thread-local variables and the fast emitter. > It only happens with the JIT, the fast emiiter and thread-locals. > (The IR passes the verifier) > > Here's the failure: > > X86CodeEmitter.cpp:516: void<unnamed>::Emitter::emitInstruction(const > llvm::MachineInstr&, const llvm::TargetInstrDesc*): Assertion...

Hi all, We have profiled [1] the memory usage in LLVM when LTO'ing Chromium, and we've found that one of the top consumers of memory is the DWARF emitter in lib/CodeGen/AsmPrinter/Dwarf*. I've been reading the DWARF emitter code and I have a few ideas in mind for how to reduce its memory consumption. One idea I've had is to restructure the emitter so that (for the most part) it directly produces the bytes and relocations that need to go in...

...g wrote: > X86 JIT does not yet support TLS. > > Evan > On Jun 12, 2009, at 2:48 AM, Mark Shannon wrote: > >> Hi there, >> >> I think I've found a bug in the x86 JIT. I get an assertion failure >> when >> using thread-local variables and the fast emitter. >> It only happens with the JIT, the fast emiiter and thread-locals. >> (The IR passes the verifier) >> >> Here's the failure: >> >> X86CodeEmitter.cpp:516: void<unnamed>::Emitter::emitInstruction(const >> llvm::MachineInstr&, const llvm::T...

Hi, Today I found a nice bug in the JIT global variable emitter. The problem may lead to an assert() failure when doing the following: 1) compile some function 2) emit a global variable 3) compile another function. an assert() may trigger in the JIT memory manager This happens because the JIT global variable emitter is using the MachineCodeEmitter::allocat...

Hello, Is it possible to activate the MIPS code emitter during Post-RA scheduler. I tried including both MipsCodeEmitter.cpp and JITCodeEmitter.h to PostRASchedulerList.cpp, but when I rebuild the compiler I get an error that says “/lib/Target/Mips/MCTargetDesc/MipsMCTargetDesc.h fatal error: MipsGenRegisterInfo.inc file not found”. I’m assuming that...

What are you actually trying to do? The code emitters have nothing to do with the post-RA scheduler. -Jim On May 30, 2013, at 6:23 AM, Jafar J <pluck90 at hotmail.com> wrote: > Hello, > > Is it possible to activate the MIPS code emitter during Post-RA scheduler. I tried including both MipsCodeEmitter.cpp and JITCodeEmitter...

...et support TLS. >> >> Evan >> On Jun 12, 2009, at 2:48 AM, Mark Shannon wrote: >> >>> Hi there, >>> >>> I think I've found a bug in the x86 JIT. I get an assertion failure >>> when >>> using thread-local variables and the fast emitter. >>> It only happens with the JIT, the fast emiiter and thread-locals. >>> (The IR passes the verifier) >>> >>> Here's the failure: >>> >>> X86CodeEmitter.cpp:516: >>> void<unnamed>::Emitter::emitInstruction(const >>...

...vm.org> wrote: >> >>> >> >>> Hi all, >> >>> >> >>> We have profiled [1] the memory usage in LLVM when LTO'ing Chromium, >> and >> >>> we've found that one of the top consumers of memory is the DWARF >> emitter in >> >>> lib/CodeGen/AsmPrinter/Dwarf*. >> >> >> >> I'm staring at the profile attached to the post #15 on the link you >> posted, can you confirm that the Dwarf emitter accounts for >> 6.7%+15.6%=22.3% of the the total allocated memory? &gt...

On Oct 13, 2008, at 2:42 PMPDT, Nuno Lopes wrote: > Hi, > > Today I found a nice bug in the JIT global variable emitter. > The problem may lead to an assert() failure when doing the following: > 1) compile some function > 2) emit a global variable > 3) compile another function. an assert() may trigger in the JIT memory > manager > > This happens because the JIT global variable emitter is using...

I noticed that the TableGen code emitter generator assumes that the instruction fields are declared in the instruction format in the same order that operands are defined. This seems like a bad dependence to me, and that TableGen should match the name of field declared in the instruction with the name of the operand in order to d...