search for: emittion

On Fri, Feb 05, 2016 at 04:58:45PM -0800, Mehdi Amini wrote: > > > On Feb 5, 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

Hi Jim, The idea of reducing the switching activity between the instructions works by reducing the hamming distance between tow consecutive binary strings across the basic block, or reducing the number of the different bits between two consecutive instructions. This is why I need the exact complete encoding in plain 0’s and 1’s, to be as precise as possible during the scheduling process. I did

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*):

On May 30, 2013, at 11:35 AM, Jafar J <pluck90 at hotmail.com> wrote: > Hi Jim, > > The idea of reducing the switching activity between the instructions works by reducing the hamming distance between tow consecutive binary strings across the basic block, or reducing the number of the different bits between two consecutive instructions. This is why I need the exact complete

Yes your absolutely right, the Opcode and the Operands in each machine instruction are sufficient to generate the final binary representation of the MachineInstruction but not exactly. If you take a look at the format of each MIPS instruction, you’ll see that there are some fixed bits for each instruction which are not available inside the machine instruction object –From what I saw so far-.

On Fri, Feb 5, 2016 at 5:51 PM Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Feb 5, 2016, at 5:40 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > > > On Fri, Feb 05, 2016 at 04:58:45PM -0800, Mehdi Amini wrote: > >> > >>> On Feb 5, 2016, at 3:17 PM, Peter Collingbourne via llvm-dev < > llvm-dev at

Hi Jafar, That’s not quite what I meant. Why do you need to know the exact encoding at all? The instruction opcode+operands should have all the semantic information you need without ever looking at the actual encoding. -Jim On May 30, 2013, at 11:08 AM, Jafar J <pluck90 at hotmail.com> wrote: > Yes your absolutely right, the Opcode and the Operands in each machine instruction are

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

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

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 On May 30, 2013, at 10:12 AM, Jafar J <pluck90 at

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: >

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

Evan, Any plans to add it any time soon? It would be really appreciated. Evan Cheng 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.

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::allocate() function, which uses memory

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 the MipsGenRegisterInfo.inc is not yet

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.h to PostRASchedulerList.cpp, but when I rebuild

No plans. I recommend you hack on it. :-) Sorry, all features are done on demand. Evan On Jun 12, 2009, at 1:08 PM, Mark Shannon wrote: > Evan, > > Any plans to add it any time soon? > It would be really appreciated. > > Evan Cheng wrote: >> X86 JIT does not yet support TLS. >> >> Evan >> On Jun 12, 2009, at 2:48 AM, Mark Shannon wrote: >>

On Fri, Feb 5, 2016 at 5:56 PM, Mehdi Amini via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On Feb 5, 2016, at 5:53 PM, Eric Christopher <echristo at gmail.com> wrote: > > > > On Fri, Feb 5, 2016 at 5:51 PM Mehdi Amini via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> > On Feb 5, 2016, at 5:40 PM, Peter Collingbourne

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

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 determine which operand of the MI to use . See