search for: mclowering

...LF, or COFF). > Would it make sense to delegate the implementation to a specialized object from current the object file format? Why? It is AsmPrinter's job to handle the lowering of MachineInstrs and LLVM IR (for globals etc) to the MC level primitives. AsmPrinter should really be renamed MCLowering at some point. > I am tempted to make it the MCAsmInfo implementation for the specific target. Currently MCAsmInfo looks just to hold useful information about the target, and not any target specific code. Right. MCAsmInfo has been designed to be filled in by targets but not subclassed. This i...

I have been looking over AsmPrinter::EmitLinkage (around line 195 of lib\CodeGen\AsmPrinter\AsmPrinter.cpp) and it seems that its implementation will vary quite a bit depending on what object file format is in use (MachO, ELF, or COFF). Would it make sense to delegate the implementation to a specialized object from current the object file format? I am tempted to make it the MCAsmInfo

...structure of a possible JIT with the MC framework. Basically : - MCJIT : - Main class implementing ExecutionEngine interface - owns and creates : - a MemoryManager (will be a reuse of the JITMemoryManager mechanism) - a MCJITStreamer - a PassManager for scheduling of an AsmPrinter (MCLowering) using the streamer - MCJITStreamer - owns and creates : - a MCAssember - a MCJITObjectWriter - a mem_raw_ostream - knows : - the MCJIT : to give it to the object writer (for mapping) - the MemoryManager : to give it to the object writer (for memory claiming) - MCJITObject...

...it make sense to delegate the implementation to a specialized > object from current the object file format? > > Why? It is AsmPrinter's job to handle the lowering of MachineInstrs and > LLVM IR (for globals etc) to the MC level primitives. AsmPrinter should > really be renamed MCLowering at some point. > > > I am tempted to make it the MCAsmInfo implementation for the specific > target. Currently MCAsmInfo looks just to hold useful information about the > target, and not any target specific code. > > Right. MCAsmInfo has been designed to be filled in by targets...

> it should be expanded late: In lib/Target/X86/X86MCInstLower.cpp. This is exactly what I was missing. Thanks a ton! :) -- Sanjoy Das http://playingwithpointers.com

On Oct 18, 2011, at 2:33 PM, Sanjoy Das wrote: >> it should be expanded late: In lib/Target/X86/X86MCInstLower.cpp. > > This is exactly what I was missing. Thanks a ton! :) We have three pseudo expansion passes: 1. ExpandISelPseudos.cpp - For instructions that may need to create basic blocks, like CMOV and atomics. 2. ExpandPostRAPseudos.cpp - For instructions used to trick the

...; Pseudos should be expanded as early as possible. Many of the instructions currently expanded in X86MCInstLower could be moved to the PostRA expansion pass. That would also allow them to be converted into pure isPseudo=1 instructions instead of just isCodeGenOnly=1. FWIW, even those expanded at MCLowering time can be pure pseudos. There is no need to use isCodeGenOnly definitions for any new code. Those that exist are pure legacy. -Jim

Hi everyone, I am in the process of adding some new code for th ARM/MC ELF emission, but noticed a curious linkage between th AsmPrinter and the MC. It looks like the MC code (on X86 at least) calls out to the (misnamed?) AsmPrinter to dump out ELF bits (in X86AsmPrinter.cpp) in the same routine, using conditional branching.... As JimG and I are working both on ARM emission stuff, I want to