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 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,
Jafar J.
From: Jim Grosbach
Sent: Thursday, May 30, 2013 9:18 PM
To: Jafar J
Cc: llvmdev at cs.uiuc.edu ; Mailing List
Subject: Re: [LLVMdev] Activating MIPS Code Emitter.
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 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-. Furthermore, how will I know how to map each operand to its right place
i.e. rt, rd, rs, immediate, offset, etc.., without knowing the semantic of the
instruction and the physical numbering of each register, to finally generate the
complete 32-bit encoding.
MachineInstr::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,
- Jafar J.
From: Jim Grosbach
Sent: Thursday, May 30, 2013 8:49 PM
To: Jafar J
Cc: llvmdev at cs.uiuc.edu ; Mailing List
Subject: Re: [LLVMdev] Activating MIPS Code Emitter.
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 hotmail.com> wrote:
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 allocation.
Thanks for the reply!
-Jafar J
From: Jim Grosbach
Sent: Thursday, May 30, 2013 7:55 PM
To: Jafar J
Cc: llvmdev at cs.uiuc.edu ; Mailing List
Subject: Re: [LLVMdev] Activating MIPS Code Emitter.
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 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 generated when I’m trying to include it in
the PostRAScheduler. Is this the way to activate the mipsCodeEmitter during
PostRA Scheduler or am I missing something here.
Thanks,
Jafar J.
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130530/de1eb8ea/attachment.html>
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 encoding in plain 0’s and 1’s, to be as precise as possible 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 going to work. First, the CodeEmitter runs as the absolute last pass. Nothing will ever come after it, and it assumes that to be true (it’s for the JIT). Second, the CodeEmitter pass is going away entirely sooner rather than later. The MCCodeEmitter takes its place. That requires lowering the instructions to MC, which again happens much later, and is required to happen much later, than the scheduler. -Jim> Sorry for the trouble! > > Thanks, > Jafar J. > > From: Jim Grosbach > Sent: Thursday, May 30, 2013 9:18 PM > To: Jafar J > Cc: llvmdev at cs.uiuc.edu ; Mailing List > Subject: Re: [LLVMdev] Activating MIPS Code Emitter. > > 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 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-. Furthermore, how will I know how to map each operand to its right place i.e. rt, rd, rs, immediate, offset, etc.., without knowing the semantic of the instruction and the physical numbering of each register, to finally generate the complete 32-bit encoding. >> >> MachineInstr::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, >> - Jafar J. >> >> From: Jim Grosbach >> Sent: Thursday, May 30, 2013 8:49 PM >> To: Jafar J >> Cc: llvmdev at cs.uiuc.edu ; Mailing List >> Subject: Re: [LLVMdev] Activating MIPS Code Emitter. >> >> >> >> 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 hotmail.com> wrote: >> >>> 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 allocation. >>> >>> Thanks for the reply! >>> >>> -Jafar J >>> >>> From: Jim Grosbach >>> Sent: Thursday, May 30, 2013 7:55 PM >>> To: Jafar J >>> Cc: llvmdev at cs.uiuc.edu ; Mailing List >>> Subject: Re: [LLVMdev] Activating MIPS Code Emitter. >>> >>> 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 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 generated when I’m trying to include it in the PostRAScheduler. Is this the way to activate the mipsCodeEmitter during PostRA Scheduler or am I missing something here. >>>> >>>> Thanks, >>>> Jafar J. >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130530/9051bbd4/attachment.html>
I’ve heard about removing the CodeEmitter Pass and replacing it with the
MCCodeEmitter, but I decided to stick with the current version I’m using.
Anyway, I really appreciate the help. I think I’ll have to think of another
solution.
Thanks,
- Jafar J.
From: Jim Grosbach
Sent: Thursday, May 30, 2013 10:44 PM
To: Jafar J
Cc: llvmdev at cs.uiuc.edu ; Mailing List
Subject: Re: [LLVMdev] Activating MIPS Code Emitter.
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 encoding in
plain 0’s and 1’s, to be as precise as possible 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 going to work. First, the CodeEmitter runs as the
absolute last pass. Nothing will ever come after it, and it assumes that to be
true (it’s for the JIT). Second, the CodeEmitter pass is going away entirely
sooner rather than later. The MCCodeEmitter takes its place. That requires
lowering the instructions to MC, which again happens much later, and is required
to happen much later, than the scheduler.
-Jim
Sorry for the trouble!
Thanks,
Jafar J.
From: Jim Grosbach
Sent: Thursday, May 30, 2013 9:18 PM
To: Jafar J
Cc: llvmdev at cs.uiuc.edu ; Mailing List
Subject: Re: [LLVMdev] Activating MIPS Code Emitter.
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 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-. Furthermore, how will I know how to map each operand to its right place
i.e. rt, rd, rs, immediate, offset, etc.., without knowing the semantic of the
instruction and the physical numbering of each register, to finally generate the
complete 32-bit encoding.
MachineInstr::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,
- Jafar J.
From: Jim Grosbach
Sent: Thursday, May 30, 2013 8:49 PM
To: Jafar J
Cc: llvmdev at cs.uiuc.edu ; Mailing List
Subject: Re: [LLVMdev] Activating MIPS Code Emitter.
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 hotmail.com> wrote:
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 allocation.
Thanks for the reply!
-Jafar J
From: Jim Grosbach
Sent: Thursday, May 30, 2013 7:55 PM
To: Jafar J
Cc: llvmdev at cs.uiuc.edu ; Mailing List
Subject: Re: [LLVMdev] Activating MIPS Code Emitter.
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 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 generated when I’m trying to include it in
the PostRAScheduler. Is this the way to activate the mipsCodeEmitter during
PostRA Scheduler or am I missing something here.
Thanks,
Jafar J.
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130530/5a558d0d/attachment.html>