search for: libcodegen

Hi, Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen? TargetInstrInfo is already halfway there with its TargetInstrInfoImpl class implementing most shared functionality. The lib/Target/TargetInstrInfo.cpp file has two remaining functions that happen to not depend on libCodeGen, but I don't think they serve any purpose as part of libTarget. Simi...

On Nov 27, 2012, at 10:24 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen? > > TargetInstrInfo is already halfway there with its TargetInstrInfoImpl class implementing most shared functionality. The lib/Target/TargetInstrInfo.cpp file has two remaining functions that happen to not depend on libCodeGen, but I don't think they serve any purpose as part of libTar...

On Nov 27, 2012, at 11:23 AM, Chris Lattner <clattner at apple.com> wrote: > On Nov 27, 2012, at 10:24 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen? >> >> TargetInstrInfo is already halfway there with its TargetInstrInfoImpl class implementing most shared functionality. The lib/Target/TargetInstrInfo.cpp file has two remaining functions that happen to not depend on libCodeGen, but I don't think they serve any purpose as part o...

...te: > > On Nov 27, 2012, at 11:23 AM, Chris Lattner <clattner at apple.com> wrote: > >> On Nov 27, 2012, at 10:24 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >>> Would anyone object to my moving the TargetRegisterInfo and TargetInstrInfo classes into libCodeGen? >>> >>> TargetInstrInfo is already halfway there with its TargetInstrInfoImpl class implementing most shared functionality. The lib/Target/TargetInstrInfo.cpp file has two remaining functions that happen to not depend on libCodeGen, but I don't think they serve any purpose a...

...cy on libAnalysis? Some of these classes (eg. MachineFunctionPass are MachineLoopInfo) seem to have a hard dependency on the Pass class in libAnalysis. Is it acceptable to carry this dependency along to the new library? Or should we be aiming to eliminate this dependency like we are with the one on libCodeGen? > Note that Passes.h would need to be provided in include/llvm/Machine so > that targets can configure their pass pipeline. The pass ID’s are extern > declared for use with TargetPassConfig, but are defined as references to > the ID field inside the pass. Those ID’s might all need to...

...ependent on Passes class but also on others such as the ConstantFolding.h. Is it a possible solution to break this dependency or carry this dependency to the Machine library as well? Regards, Nitish B. -- View this message in context: http://llvm.1065342.n5.nabble.com/Extracting-libmachine-from-libcodegen-bug-1121-tp60984p62500.html Sent from the LLVM - Dev mailing list archive at Nabble.com.

On Sep 5, 2013, at 5:15 PM, Ken Dyck <kd at kendyck.com> wrote: > Hi, > > One of the long-standing code clean-up bugs in Bugzilla is to extract > the Machine* code from the CodeGen library into a separate one, on > which CodeGen depends ( > http://llvm.org/bugs/show_bug.cgi?id=1121). > > I'd like to start working on this. The general approach I'm planning

Hi, One of the long-standing code clean-up bugs in Bugzilla is to extract the Machine* code from the CodeGen library into a separate one, on which CodeGen depends ( http://llvm.org/bugs/show_bug.cgi?id=1121). I'd like to start working on this. The general approach I'm planning to take is: 1. Identify which code to move. 2. Eliminate all dependencies that the Machine code has on the

I tried llc -load /localhome/aggarwa4/llvm27/llvm-obj/projects/poolalloc/Debug/lib/libCodegen.so --help But this does not show my pass. It says it is an unknown command line argument. Arushi On Thu, May 12, 2011 at 11:21 AM, John Criswell <criswell at illinois.edu> wrote: > On 5/12/11 11:17 AM, Arushi Aggarwal wrote: >> >> What is the correct way to register/run a ma...

On 5/12/11 11:46 AM, Arushi Aggarwal wrote: > I tried > llc -load /localhome/aggarwa4/llvm27/llvm-obj/projects/poolalloc/Debug/lib/libCodegen.so > --help > > But this does not show my pass. It says it is an unknown command line argument. I'm assuming you've looked at other MachineFunctionPass'es and have registered yours in the same way that they do. I don't think they're registered like regular LLVM pass...

...es like MachineRegisterInfo are also expected to be present. I am looking for a volunteer to build the scaffolding required in unittests/CodeGen to make it possible to write unit tests for MachineFunction and associated classes. You would need to: - Set up a unittests/CodeGen target that links in libCodeGen. - Create a mock target with minimal functionality, preferably without depending on TableGen. - Provide an easy way for individual tests to get a MachineFunction instance with the required decorations. This would be a good way to learn about target and codegen configuration. /jakob

On Friday 10 July 2009 00:19, Chris Lattner wrote: > asmprinter::printInstruction will lower a MachineInstr to an MCInst, > then call the MCInst asmprinter to do the hard formatting work. You > can see a horrible simple skeleton of this idea in > X86ATTAsmPrinter::printMachineInstruction. Yep, that's where I hit the problem. I'm patching the sources for the comment emitter

What is the correct way to register/run a machine function pass, so that it can be dynamically loaded? Thanks, Arushi

On 5/12/11 11:17 AM, Arushi Aggarwal wrote: > What is the correct way to register/run a machine function pass, so > that it can be dynamically loaded? Machine function passes are loaded into llc to be used for code generation, from the looks of it. Does this answer your question? -- John T. > Thanks, > Arushi > _______________________________________________ > LLVM

...rsion of asmprinter:printInstruction (which I'm working on). A strong goal for me is to make it so that we can build very small (as in code size) assembler and disassembler tools. This means that none of this stuff can depend on (e.g.) libx86, because that brings in the huge target plus libcodegen plus libtarget plus vmcore, ... etc. As a key part of this factoring, instruction asmprinting (for example) will no longer work directly on MachineInstr. Instead, asmprinter::printInstruction will lower a MachineInstr to an MCInst, then call the MCInst asmprinter to do the hard formatting...

Can someone explain what MCInst is vs. MachineIntr? I'm porting some patches we have here that affect MachineInstrs and am wondering whether I need to make similar changes in MCInst. Why do we have two machine instruction representations? -Dave

Context: We use MCJIT to generate machine code in our LLVM based JIT compiler. The code generation process has roughly 5 steps: 0. Generate and optimize LLVM IR. 1. Call generateCodeForModule on the output of (0) to translate LLVM IR to machine code. 2. Figure out the final locations for the code and data generated by MCJIT using an allocator specific to our runtime. Make

I'm linking a program (my ellsif driver) that basically brings in most of the LLVM stuff: bitcode reading, optimizations, linking, and target code generation. All of a sudden, I'm getting the following when I run: [~/elsa/ellsif] dev% ./ellsif -v test/ofmt.i test/sieve.i -time-actions -O5 <premain>: CommandLine Error: Argument 'machine-licm' defined more than once!

On Wed, 1 Jul 2015 at 08:19 Stephen Cross <scross at scross.co.uk> wrote: > Hi everyone, > > I was wondering if anyone could answer the questions in my first > email. These were: > > * Why does Clang generate 8 byte alignment for 16+ byte arrays on > x86-64, even though the AMD64 ABI seems to require 16 byte alignment? > * Clang has some logic in