search for: mcinstr

Hello! Can someone please tell me if is there an API (or some other way) to query MCInstrDesc to find out the type of its memory operands? As an example, consider the following description of MOV32mr (from X86InstrInfo.td) def MOV32mr : I<0x89, MRMDestMem, (outs), (ins i32mem:$dst, GR32:$src), "mov{l}\t{$src, $dst|$dst, $src}", [(store GR32...

+Ahmed > On Mar 2, 2018, at 6:42 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com> wrote: > > There are a number of people on llvm-dev who can explain better than I how to decompile into MachineInstrs. I’m not totally opposed to checking in something that works with MCInstr, but this does run strongly contrary to the design of LLVM’s subtarget support. > > That would be great! I would be very happy if somebody suggests how to do it (or does it for me :-)). I know that’s it’s been done before, it’s an extremely useful technique, and work in that direction shoul...

Could you please expand a bit? Why are not the MCInstr and MachineInstr classes compatible? Is this not a long term goal, even? Could I make optimization passes in the MC layer with a disassembler as in a MachineFunction? Thanks, Jonas -----Original Message----- From: Eric Christopher [mailto:echristo at apple.com] Sent: Friday, February 17, 2012...

Hello, I'm using the MCInsrAnalysis and would like to extend it to have methods like: * bool mayWritePC(MCInstr * Instr); returns true if Inst might write to the PC, i.e. might change the program flow * uint64_t evaluateLoadAddress(MCInstr * Instr, uint64_t Addr, uint64_t Size); returns the address that Instr will load from if can be calculated Does anyone have any thoughts or mind me d...

...to concatenate to registers' names (which I am doing during assembly printing). Also just Updating some status for my questioin: I have continued with using *Defs* list. It allows me to keep Registers as an implicit operands of /*MachineInstr*/ and later during its lowering pass them to the /*MCInstr*/. Now seems I need only to change */printInstruction()/* function to Emit this instructions in appropriate way. For that I need to change /*utils/TableGen/AsmWriterEmitter.cpp: AsmWriterEmitter::EmitPrintInstruction*/ to generate appropriate code in "/TARGETGenAsmWriter.inc/" file. But...

Hi all After codegen for a given function, the IR should no longer be needed. In the AsmPrinter we convert from MI->MCInstr, and then we never go back and look at the IR during the MC layer. I’ve prototyped a simple pass which can be (optionally) scheduled to do just this. It is added at the end of addPassesToEmitFile. It is optional so that clang can continue to leak the IR with --disable-free, but i would propose t...

...M, Andrea Di Biagio <andrea.dibiagio at gmail.com <mailto:andrea.dibiagio at gmail.com>> wrote: >> >> There are a number of people on llvm-dev who can explain better than I how to decompile into MachineInstrs. I’m not totally opposed to checking in something that works with MCInstr, but this does run strongly contrary to the design of LLVM’s subtarget support. >> >> That would be great! I would be very happy if somebody suggests how to do it (or does it for me :-)). > > I know that’s it’s been done before, it’s an extremely useful technique, and work in th...

...> > Interesting. I couldn't find how to do it. It would be great if somebody helps me on this. I was thinking of APIs like MachineOperand::readsReg(). I guess if you’re only asking whether an instruction zeros the upper part of the register, that information *should* be available from MCInstr/MCRegisterInfo, but I’m not very familiar with the API. Matthias? -Andy > 1) Partial register updates versus full register updates. > > On x86-64, a 32-bit GPR write fully updates the super-register. Example: > add %edi %eax ## eax += edi > > Here, register %eax alia...

...Many apps would benefit from a stable API for doing this. -- lg > On Mar 7, 2016, at 4:55 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > After codegen for a given function, the IR should no longer be needed. In the AsmPrinter we convert from MI->MCInstr, and then we never go back and look at the IR during the MC layer. > > I’ve prototyped a simple pass which can be (optionally) scheduled to do just this. It is added at the end of addPassesToEmitFile. It is optional so that clang can continue to leak the IR with --disable-free, but i would...

...le API for doing this. > > -- lg > > >> On Mar 7, 2016, at 4:55 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> >> After codegen for a given function, the IR should no longer be needed. In the AsmPrinter we convert from MI->MCInstr, and then we never go back and look at the IR during the MC layer. >> >> I’ve prototyped a simple pass which can be (optionally) scheduled to do just this. It is added at the end of addPassesToEmitFile. It is optional so that clang can continue to leak the IR with --disable-free, but...

...(as in Google's Native Client), just a set of standard libraries providing wrappers to OS-level syscalls all compiled as llvm bitcode. Am I right in thinking that the opcode information for each architecture is all defined by the TableGen tables, and a modification to that and the underlying MCInstr infrastructure is all that is required? This is all very blue-sky thinking at the moment, but I may be able to do some of the development required once I have the opinions of those who know the guts of llvm better than I. Many thanks Rick Taylor Tropical Storm Software Ltd. -----------...

Hi, I would like to make a disassembler for my target that reads .s files into a MachineFunction with MachineInstrs. Is this possible? Jonas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120217/ab433f19/attachment.html>

On Feb 17, 2012, at 7:18 AM, Jonas Paulsson <jonas.paulsson at ericsson.com> wrote: > Hi, > > I would like to make a disassembler for my target that reads .s files into a MachineFunction with MachineInstrs. Is this possible? > Nope. -eric

...ality, if the properties of its operands meet certain criteria. Thus on the MI layer, we check the properties of the instruction's operands, and use the information for scheduling, and on the MC layer, we check the properties of the instruction's operands, and perform the conversion to the MCInstr's more compact form. The API to access Operands was similar enough such that I was able to write a template where I could use a construct: template <typename T>unsigned myFunc(T Mx) { Mx->getOperand(0).getReg(); Mx->getOperand(1).getReg(); Mx->getOperand(2).isImm();...

...not so much at teaching how to use the code. > > Patches adding comments are also a good way to learn how something works. You send a comment, people say how wrong that is, and in the end, you learn by teaching others via your comments. This is especially true in the back end. For example, MCInstrDesc[1] completely lacks any class-level doc comment saying how you would map from an instruction to the description. It turns out that each back end exposes an array of MCInstrDesc objects, indexed by opcode (in the MCInstr sense, not in the target instruction set sense), but the only way to disco...

Hi all, My question is related to the register usage in instruction definition at TARGETInstrInfo.td file. I have defined new Target with it Registers and instructions. Now I need to generate an instruction like: mov MYREG1_NAME, MYREG2_NAME for the built-in function taking one constant integer argument, such as "__builtin_my_function_name(88)" I wondering whether it is possible

...quot;. For > loads, > the scheduling model provides an "optimistic" load-to-use latency (which > usually > matches the load-to-use latency for when there is a hit in the L1D). > > > You’re optimistic here, which is good, but pessimistic with aliasing. > > Class MCInstrDesc in LLVM doesn't know about serializing operations, nor > memory-barrier like instructions. LSUnit conservatively assumes that an > instruction which has both 'MayLoad' and 'UnmodeledSideEffects' behaves > like a > "soft" load-barrier. That means, it s...

...M, Andrea Di Biagio <andrea.dibiagio at gmail.com <mailto:andrea.dibiagio at gmail.com>> wrote: >> >> There are a number of people on llvm-dev who can explain better than I how to decompile into MachineInstrs. I’m not totally opposed to checking in something that works with MCInstr, but this does run strongly contrary to the design of LLVM’s subtarget support. >> >> That would be great! I would be very happy if somebody suggests how to do it (or does it for me :-)). > > I know that’s it’s been done before, it’s an extremely useful technique, and work in th...

On 25 September 2013 22:13, Preston Briggs <preston.briggs at gmail.com> wrote: > A lot of my difficulty in reading other examples is that it's not clear > what matters and what doesn't. It's what I hope to get by sitting next to > someone and asking questions. Some of this could be addressed in a guide. > I'd start with a chapter on planning. > Another

...quot; and/or "MayStore". For loads, > the scheduling model provides an "optimistic" load-to-use latency (which usually > matches the load-to-use latency for when there is a hit in the L1D). You’re optimistic here, which is good, but pessimistic with aliasing. > Class MCInstrDesc in LLVM doesn't know about serializing operations, nor > memory-barrier like instructions. LSUnit conservatively assumes that an > instruction which has both 'MayLoad' and 'UnmodeledSideEffects' behaves like a > "soft" load-barrier. That means, it serial...