similar to: [LLVMdev] Volunteers needed: Unit test scaffolding for lib/CodeGen

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

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.

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

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

On Wed, Sep 11, 2013 at 12:29 AM, Andrew Trick <atrick at apple.com> wrote: > > If that is the goal, then you only want the modules for Machine IR, and maybe some core analysis passes. The “Machine” modules you listed above include machine code analysis or transform passes that you probably don’t want. Pruning the list to basic IR support: > >> - MachineBasicBlock >> -

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

On Nov 27, 2012, at 11:51 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > 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?

When writing MachineFunction unit tests, I find it quite tedious to verify correctness in C++. I would like to use FileCheck in UnitTests because FileCheck is extremely convenient/robust to verify correctness. In order to do so, I moved most of FileCheck’s implementation into a header (Support/FileCheck.h) and updated FileCheck.cpp to use this. I ran into this while writing some target agnostic

> On 2 Jul 2018, at 15:13, Matthias Braun via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I had similar gripes with unit testing machine function stuff. I personally would have preferred to create more tests based on a tool like llc rather than pushing more on the unit test side. Anyway I tried to push https://reviews.llvm.org/D48850 <https://reviews.llvm.org/D48850> in

David, Dean, all, The bots got red today with assertion failures in llvm::DbgVariable::addMMIEntry: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/1816/steps/check-msan%20in%20gcc%20build/logs/stdio I did not find the offender yet. Any ideas? clang-5.0: /mnt/b/sanitizer-buildbot1/sanitizer-x86_64-linux/build/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.h:131: void

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 machine

Thanks! On Mon, May 8, 2017 at 6:25 PM, Reid Kleckner <rnk at google.com> wrote: > I give it 99% odds it was r302483. Let's revert and debug it tomorrow. > > On Mon, May 8, 2017 at 6:20 PM, Kostya Serebryany via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> David, Dean, all, >> >> The bots got red today with assertion failures in >>

I tried debugging it and the issue seems to be in the implementation of MachineInstrIterator.h and the way it interacts with GraphWriter.h functions. I found this by replacing the ( template <> struct GraphTraits<MCDFGraph<MachineFunction*> >) with a similar MCDFGraph based template of CFG similar to the one in MachineFunction.h (similarly replacing the DOTGraphTraits with the

One thing I want to mention. I believe in the current legacy pass manager implementation only one MachineFunction ever exists at a time. It is deleted before the next MachineFunction is created. This is very important for memory usage. I think the MachineOutliner being in the pipeline may create an exception to this. I think the initial version of retpoline used a ModulePass and that had to be

Hi all, I am really stumped on a problem for long. I could not figure out why. That is why i am here. OK, here is the problem: I tried to insert a MachineBasicBlock into a function. Here is the code snippet: // insert a machine basic block with the error_label into MF and before I // Pred is the predecessor of the block to be inserted // the new basic block is inserted right before I void

Hi, I am trying to generate the DFG of machine functions. Initially, I added a pass to generate the DFG of LLVM IR functions. This was based on the mail thread - http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025582.html. This pass worked fine and I was able to generate DFG of LLVM IR functions. Later, I ported the DFG pass code for machine functions. I ported the InstIterator.h

I was running into a problem with compiling llvm with gcc 4.4 on fedora 11 with --enable-optimized. I was seeing this warning dozens of times: /net/hakodate/scratch/llvm/llvm/include/llvm/CodeGen/ValueTypes.h: In member function ‘llvm::SDNode*<unnamed>::SPUDAGToDAGISel::Select(llvm::SDValue)’: /net/hakodate/scratch/llvm/llvm/include/llvm/CodeGen/ValueTypes.h:362: warning: comparison always

Kenneth Uildriks wrote: > > Does the error function *have* to be auto-generated in your pass? > Perhaps the original code should use invokes, and your pass insert the > error check with a jne to the "unwind" block. > If I understand correctly, unwind is some kind of exception handling in LLVM IR? I'm not sure if this is the right thing. First, I include runtime

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

Dear there, I am trying to use liveness of a variable while writing a machinefunction pass. But it seems that some virtual registers are not marked as dead while they should be (never used by anything else). I get those info by callings isDead or isDef function for that MachineOperand (vreg). Is there a way to get more accurate liveness info? Thanks, Xiaochu -------------- next part