similar to: [LLVMdev] Machine Level IR text-based serialization

2015-04-28 10:15 GMT-07:00 Hal Finkel <hfinkel at anl.gov>: > > ------------------------------ > > *From: *"Alex L" <arphaman at gmail.com> > *To: *"LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > *Sent: *Tuesday, April 28, 2015 11:56:42 AM > *Subject: *[LLVMdev] RFC: Machine Level IR text-based serialization format > >

To get this out first: I'd love to have a way to serialize machine-IR! I often spend a lot of time trying to create .ll files in a way that the machine-IR still looks a certain way when it finally hits the relevant passes in codegen. It would be so much easier to just specify the machine IR immediately before the pass I'm interested in. For that use case it is worth keeping the following

Hi all, I am trying to build a global control flow graph at machine code level. Essentially, I need the handles to the MachineFunction's corresponding to every call site inside a MachineFunction in order to get the handles to MachineBasicBlock's with return statements inside the callee. Currently, the codegen module processes one MachineFunction at a time and hence I can't find a way

2015-04-28 10:09 GMT-07:00 Krzysztof Parzyszek <kparzysz at codeaurora.org>: > Looks good. How are you planning to "assemble" the MI-level YAML > description into the actual in-memory IR? I plan on developing a parser for the new text format for the machine instructions. This parser will parse instructions, operands and memory operands, and it will after run the machine

Hi Abhishek, On Sunday, July 29, 2012 18:32:11 AbhishekR wrote: > It seems like I may have to modify the way MachineFunction is instantiated in MachineFunctionAnalysis. Instead of doing it per Function, it may have to be done for the entire Module by instantiating MachineFunction objects for every Function inside the Module. This might require major changes to the PassManager framework as well.

> On 2015 Apr 29, at 19:13, Hayden Livingston <halivingston at gmail.com> wrote: > > What is missing in the current textual format that doesn't allow going > all the way to machine code? Nothing. What's missing is the ability to serialize the machine level itself. Since many passes have to run to get from .ll to .s, it's currently hard (impossible?) to test

Hello, I have question about the overhead in lapply. x is a list of 3000 lists. Each of the i (1<=i<=3000) list elements is pair of two elements: a string vector and a data frame x is roughly 235MB. > gc() ## > z <- system.time(y <- lapply(x,function(r){ system.time(serialize(r,NULL))['elapsed'] })) > sum(unlist(y)) 18.812 > z user system elapsed 494.144

Hello, I'm looking for examples of how to handle serialization of external pointers. We use external pointers intensively in Rcpp for modules and one popular request is to have persistence. And I guess we need to be able to serialize/deserialize external pointers for this. Also, module objects are all instances of reference classes, so maybe that can be handled at the R level ? Romain

Dear R developers, The slow performance of serializing to a raw vector on Windows is an issue that has appeared in this list before. It appears to be due to the frequent use of realloc from the resize_buffer method in serialize.c. I suggest a more granular, but still incremental, re-allocation of memory. For example change near the top of resize_buffer to: R_size_t newsize = needed + 65536 -

Hi all, I would like to propose a text-based, human readable format that will be used to serialize the machine level IR. The major goal of this format is to allow LLVM to save the machine level IR after any code generation pass and then to load it again and continue running passes on the machine level IR. The primary use case of this format is to enable easier testing process for the code

2015-04-29 11:40 GMT-07:00 Duncan P. N. Exon Smith <dexonsmith at apple.com>: > > > On 2015-Apr-29, at 06:40, Krzysztof Parzyszek <kparzysz at codeaurora.org> > wrote: > > > > On 4/28/2015 7:13 PM, Alex L wrote: > >> > >> > >> 2015-04-28 16:26 GMT-07:00 Matthias Braun <matze at braunis.de > >> <mailto:matze at

2015-04-28 10:14 GMT-07:00 Quentin Colombet <qcolombet at apple.com>: > Hi Alex, > > Thanks for working on this. > > Personally I would rather not have to write YAML inputs but instead resort > on the what the machine dumps look like. That being said, I can live with > YAML :). > > More importantly, how do you plan to report syntax errors to the users? > Things

Did someone make a change in MachineFunction and forget to update something? g++ -I/Volumes/data/Wendling/llvm-submission/build/obj/obj-llvm/lib/CodeGen -I/Volumes/data/Wendling/llvm-submission/build/obj/src/llvm/lib/CodeGen -I/Volumes/data/Wendling/llvm-submission/build/obj/obj-llvm/include -I/Volumes/data/Wendling/llvm-submission/build/obj/src/llvm/include

Dear all, I have quite large code (with lapply and mclapply) and I am getting the following error. Error: serialization is too large to store in a raw vector Is it possible to ask from R to extend the Error messages with more details? I would like to see where this problem exists. B.R Alex [[alternative HTML version deleted]]

Hi I have a ModulePass in LLC that runs after most of codegen completes, right before OBJ emission. I want the ModulePass to iterate over all MachineFunctions, emulating them. I used to do this by iterating over all Module Function's, and using MachineFunction::get() to get the MachineFunction associated with said Function. In LLVM 2.6, MachineFunction::get() is gone. What is the new way

On Tue, Apr 28, 2015 at 3:51 PM, David Majnemer <david.majnemer at gmail.com> wrote: > I love the idea of having some sort of textual representation. My only > concern is that our YAML parser is not very actively maintained (is there > someone expert with its implementation *and* active in the project?) and > (IMHO) over-engineered when compared to the simplicity of our custom

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

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 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

Hello, I propose a new syntax for metadata strings (MDStrings) which would allow string data to be spread over multiple lines: !0 = metadata !{metadata !""" hello world """} The special three-quote sequence marks the beginning and end of a multi-line string. This syntax could have a variety of uses, but of particular interest is that it could be used as a basis