search for: mcinstrinfo

Is this function required? MCInstrInfo::getName(OpCode) returns the same string, and we have two copies of the string table now. Can MCInstrPrinter refer to MCInstrInfo, and why not? /jakob

On Mar 30, 2012, at 3:12 PM, Benjamin Kramer <benny.kra at googlemail.com> wrote: > > On 30.03.2012, at 23:30, Jakob Stoklund Olesen wrote: > >> Is this function required? >> >> MCInstrInfo::getName(OpCode) returns the same string, and we have two copies of the string table now. >> >> Can MCInstrPrinter refer to MCInstrInfo, and why not? > > I looked into this at some point and if my memory serves me correctly using MCInstrInfo in the printer would create a cyclic...

On 30.03.2012, at 23:30, Jakob Stoklund Olesen wrote: > Is this function required? > > MCInstrInfo::getName(OpCode) returns the same string, and we have two copies of the string table now. > > Can MCInstrPrinter refer to MCInstrInfo, and why not? I looked into this at some point and if my memory serves me correctly using MCInstrInfo in the printer would create a cyclic dependency between...

...eryone! There is segmentation fault during translating a simple function with my backend. Investigation with gdb has shown that address of InstrNameData array in generated file MyTargetGenInstrInfo.inc is out of bounds. Also, if I run llc without -view-dag options, NumOpcodes equals 0 inside llvm::MCInstrInfo::get function, although there are some instructions (they are appeared in MyTargetGenInstrInfo.inc file). File MyTargetMCTargetDesc.cpp contains createMyTargetMcInstrInfo() function and appropriate RegisterMCInstrInfo() call. Could someone, please, advise me what can I do with it? Regards, Vadi...

...processes using LLVM. It turns out that a solid ~1.3MB of that data is in the tablegen'd MCInstrDesc tables - there a pointers for ImplicitUses, ImplicitDefs, and OpInfo that need to be relocated. This can be fixed of course by having target-global arrays for those structures referenced by MCInstrInfo (and hence TargetInstrInfo), and only storing offsets into those global arrays in MCInstrDesc. The downside is that several relevant accessors need to be augmented with MCInstrInfo parameters, but in the long run it seems worth it to me. Any objections or suggestions? Is this something that peo...

...a solid ~1.3MB of that data is in the tablegen'd >> MCInstrDesc tables - there a pointers for ImplicitUses, ImplicitDefs, and >> OpInfo that need to be relocated. >> >> This can be fixed of course by having target-global arrays for those >> structures referenced by MCInstrInfo (and hence TargetInstrInfo), and only >> storing offsets into those global arrays in MCInstrDesc. >> >> The downside is that several relevant accessors need to be augmented with >> MCInstrInfo parameters, but in the long run it seems worth it to me. >> >> Any obj...

...GET_INSTRINFO_ENUM #include "AArch64GenInstrInfo.inc" #define GET_SUBTARGETINFO_ENUM #include "AArch64GenSubtargetInfo.inc" #include "llvm/MC/MCSchedule.h" #include "llvm/MC/MCRegisterInfo.h" #include "llvm/MC/MCInstrDesc.h" #include "llvm/MC/MCInstrInfo.h" #include "llvm/MC/SubtargetFeature.h" #include "llvm/MC/MCSubtargetInfo.h" #define GET_INSTRINFO_MC_DESC #include "AArch64GenInstrInfo.inc" #define GET_SUBTARGETINFO_MC_DESC #include "AArch64GenSubtargetInfo.inc" #define GET_REGINFO_MC_DESC #includ...

...4GenInstrInfo.inc" > > #define GET_SUBTARGETINFO_ENUM > #include "AArch64GenSubtargetInfo.inc" > > #include "llvm/MC/MCSchedule.h" > #include "llvm/MC/MCRegisterInfo.h" > #include "llvm/MC/MCInstrDesc.h" > #include "llvm/MC/MCInstrInfo.h" > #include "llvm/MC/SubtargetFeature.h" > #include "llvm/MC/MCSubtargetInfo.h" > > #define GET_INSTRINFO_MC_DESC > #include "AArch64GenInstrInfo.inc" > > #define GET_SUBTARGETINFO_MC_DESC > #include "AArch64GenSubtargetInfo.inc&qu...

Hello all, Is there an easy way to get the human-readable opcode mnemonic (e.g., "MOV32ri64", "CMP32ri8", "JLE_1") for a MachineInstr? I am writing a backend analysis pass for security research, where the idea is for a researcher to examine the output of my pass and identify instructions from it for use in an attack. Right now I'm representing unique

Hello LLVM, I'd like to check TSFlags in my AsmBackend code. However AsmBackend objects don't have a reference to MCInstrInfo, which is the only way I've seen to reach TSFlags. A quickie grep shows that none of the existing targets check TSFlags in their AsmBackends. Is there any reason I shouldn't check TSFlags in AsmBackend? If not, what's the best way to go about it? Thanks, -steve

...a later Pass can work on them. To do so I load a dummy .ll file created from a main stub, create the needed function stubs (ModulePass), insert Blocks and create instructions using BuildMI. I started with branch instructions:     const TargetMachine &TM = MF.getTarget();     const MCInstrInfo *TII = TM.getMCInstrInfo();     DebugLoc DL;     BuildMI(BB, BB.end(), DL, TII->get(ARM::B)).addMBB(trgBlock); these are working fine. When creating an compare instruction like cmp r0, 1 with:      BuildMI(BB, BB.end(), DL, TII->get(ARM::tCMPi8),0).addImm(1); I get the follo...

...rgets have historically been building hooks into > TargetInstrInfo. > > To be clear then, resolveSchedClass should be moved from TargetSchedModel > into MCSchedModel (which is where I originally wanted it). Any > TargetInstrInfo APIs called from SchedPredicate should be moved to > MCInstrInfo, which should be straightforward but annoying. > Personally, I don't have a strong opinion on this. My major concern is that not all predicates can be easily rewritten/adapted to work with MCInst and MCschedModel. Predicates can potentially access information which is not normally reachabl...

...> #define GET_SUBTARGETINFO_ENUM > > #include "AArch64GenSubtargetInfo.inc" > > > > #include "llvm/MC/MCSchedule.h" > > #include "llvm/MC/MCRegisterInfo.h" > > #include "llvm/MC/MCInstrDesc.h" > > #include "llvm/MC/MCInstrInfo.h" > > #include "llvm/MC/SubtargetFeature.h" > > #include "llvm/MC/MCSubtargetInfo.h" > > > > #define GET_INSTRINFO_MC_DESC > > #include "AArch64GenInstrInfo.inc" > > > > #define GET_SUBTARGETINFO_MC_DESC > > #includ...

...ined reference to `(anonymous namespace)::TestAsmParser::ComputeAvailableFeatures(unsigned long) const'* collect2: error: ld returned 1 exit status ---------------- and here is the code that it refers to: TestAsmParser(MCSubtargetInfo &sti, MCAsmParser &parser, const MCInstrInfo &MII, const MCTargetOptions &Options) : MCTargetAsmParser(), STI(sti), Parser(parser) { // Initialize the set of available features. setAvailableFeatures(ComputeAvailableFeatures(STI.getFeatureBits())); } Destructors for both TestAsmParser and MCTargetAsmParser class are a...

...ar 6, 2018, at 4:20 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com> wrote: > > To be clear then, resolveSchedClass should be moved from TargetSchedModel into MCSchedModel (which is where I originally wanted it). Any TargetInstrInfo APIs called from SchedPredicate should be moved to MCInstrInfo, which should be straightforward but annoying. > > Personally, I don't have a strong opinion on this. > My major concern is that not all predicates can be easily rewritten/adapted to work with MCInst and MCschedModel. > > Predicates can potentially access information which is n...

Thank you Mr. Tim. I was wondering if you can tell me in which file 'get()' is defined. I am having trouble using this function. For example if I write 'get(AArch64::LDRXui)' then there is an error generated which says: use of undeclared identifier 'get'. Thanks again !! On Fri, Oct 3, 2014 at 9:56 PM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi

...k on them. > To do so I load a dummy .ll file created from a main stub, create the needed function stubs (ModulePass), insert Blocks and create instructions using BuildMI. > I started with branch instructions: > > const TargetMachine &TM = MF.getTarget(); > const MCInstrInfo *TII = TM.getMCInstrInfo(); > DebugLoc DL; > BuildMI(BB, BB.end(), DL, TII->get(ARM::B)).addMBB(trgBlock); > > these are working fine. > When creating an compare instruction like cmp r0, 1 with: > > BuildMI(BB, BB.end(), DL, TII->get(ARM::tCMPi8...

...- Matthias Unfortunately targets have historically been building hooks into TargetInstrInfo. To be clear then, resolveSchedClass should be moved from TargetSchedModel into MCSchedModel (which is where I originally wanted it). Any TargetInstrInfo APIs called from SchedPredicate should be moved to MCInstrInfo, which should be straightforward but annoying. I just looked at the x86 target, and I’m surprised that none of the in tree x86 machine models are using SchedPredicate, so this isn't really a limitation for the current incarnation of the MCA tool. -Andy -------------- next part --------------...

...o do so I load a dummy .ll file created from a main stub, create the needed function stubs (ModulePass), insert Blocks and create instructions using BuildMI. >> I started with branch instructions: >> >> const TargetMachine &TM = MF.getTarget(); >> const MCInstrInfo *TII = TM.getMCInstrInfo(); >> DebugLoc DL; >> BuildMI(BB, BB.end(), DL, TII->get(ARM::B)).addMBB(trgBlock); >> >> these are working fine. >> When creating an compare instruction like cmp r0, 1 with: >> >> BuildMI(BB, BB.end()...

...id=32325> tracks some of these issues). The goal of the tool presented here is to automatically (in)validate the TableDef scheduling models. In the long run we envision automatic generation of the models. At Google, we have developed a tool that, given an instruction mnemonic, uses the data in `MCInstrInfo` to generate a code snippet that makes execution as serial (resp. as parallel) as possible so that we can measure the latency (resp. uop decomposition) of the instruction. The code snippet is jitted and executed on the host subtarget. The time taken (resp. resource usage) is measured using hardware...