similar to: [LLVMdev] global control flow graph at machine code level

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.

For the following code: struct XBeePacket; typedef void (*CompletionProc)(XBeePacket* inPacket, void* inParam2); struct XBeePacket { bool mField1; CompletionProc mCompletionProc; }; Why does clang emit this IR? %struct.XBeePacket = type { i8, {}* } define void @MyCompletionProc(%struct.XBeePacket* %inPacket, i8*

Hi Rick, this is a bug in Clang's LLVM-IR code generator: http://llvm.org/bugs/show_bug.cgi?id=14920 Best, Florian On Sunday, January 20, 2013 01:57:37 Rick Mann wrote: > For the following code: > > struct XBeePacket; > > typedef void (*CompletionProc)(XBeePacket* inPacket, void* inParam2); > > struct > XBeePacket > { >

On Wed July 11 2012 11:50:01 Chandler Carruth wrote: > - What else did I miss? > > > Things that are totally out of scope: pass registration, the current pass order and structure, the fundamental interface of mapping from a pass to an analysis, etc. This is really about pass management and scheduling. > Hi Chandler, I understand why the pass registration and the pass

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

Greetings folks! In working on a new optimization pass (splitting cold regions into separate functions based on branch probabilities) I've run into some limitations of the current pass manager infrastructure. After chatting about this with Nick, it seems that there are some pretty systematic weaknesses of the current design and implementation (but not with the fundamental concepts or

Hi Quentin, > On 22 Jan 2016, at 15:16, Quentin Colombet <qcolombet at apple.com> wrote: > 1. If anyone else is interested for such concept? yes, we are! (https://github.com/t-crest) > 2. What kind of information should we make accessible in an hypothetical MachineModule? I.e., how do you plan to use the MachineModulePass so that we make the right design decisions for the

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 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 all, I like all the ideas so far. Here are my thoughts: I think that fundamentally users of LLVM should be able to opt-in to more aggressive or intensive computation at compile time if they wish. Users' needs differ, and while a 33% increase in clang LTO is absolutely out of the question for some people, for those developing microcontrollers or HPC applications that may well be

Hi everyone, vmkit requires to know the size of a jitted method before emitting the method. This allows to allocate the correct size for the method. The attached patch creates this functionality when the flag SizedMemoryCode is on. In order to implement this functionality, i had to virtualize some MachineCodeEmitter functions. Is it OK to commit the patch? Thanks, Nicolas --------------

*Vivek Pandya* On Fri, Mar 18, 2016 at 10:03 PM, Quentin Colombet <qcolombet at apple.com> wrote: > Hi Vivek, > > On Mar 16, 2016, at 1:00 PM, vivek pandya via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hello, > > Probably this may be too late to start thinking about this project but I > think this is particularly useful feature for LLVM. >

Hi Evan, Evan Cheng wrote: > 1) How are you computing size of the method being > jitted? I add a new pass with addSimpleCodeEmitter, with the emitter being a SizeEmitter. Since the target calls the emitter with functions such as writeByte, writeWord, etc.... the SizeEmitter class implements these function by incrementing a counter. At the end of the pass, the code size of the

Evan Cheng wrote: > On Apr 1, 2008, at 12:50 AM, Nicolas Geoffray wrote: > > > That's a hack. :-) It is if you think that code emitter should only be used for actually writing somewhere the data. It is not if you find it another useful utility ;-) > Some targets already have ways to compute the exact > size of a function. See ARM::GetFunctionSize()

Evan Cheng wrote: > > Let's see. ARM has it already. PPC has getNumBytesForInstruction so > you only need to add one to compute function size. Also you only need > to implement it for targets that support JIT right now, which leaves > Alpha and X86. I'm guessing Alpha is using fixed encoding so it should > be pretty easy. Or you can just punt it and let the target

Hi, Two questions. 1) How are you computing size of the method being jitted? 2) Why not simply add the functionality of allocating emission buffer of specific size to MachineCodeEmitter instead? Thanks, Evan On Mar 30, 2008, at 12:05 PM, Nicolas Geoffray wrote: > Hi everyone, > > vmkit requires to know the size of a jitted method before emitting > the method. This allows to

Hello, Probably this may be too late to start thinking about this project but I think this is particularly useful feature for LLVM. A quick use I can think of this is Implementing Inter-procedural Register Allocation ( for Research purpose ). I have start looking at the code for MachineFunctionPass, I think currently MachineModule class is not available ( the project work will include that ) but

On Apr 1, 2008, at 12:50 AM, Nicolas Geoffray wrote: > Hi Evan, > > Evan Cheng wrote: >> 1) How are you computing size of the method being >> jitted? > > I add a new pass with addSimpleCodeEmitter, with the emitter being a > SizeEmitter. Since the target calls the emitter with functions such as > writeByte, writeWord, etc.... the SizeEmitter class implements these

Hi everyone, Here's a patch that enables exception handling when jitting. I've copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may need to factorize it, but the functionality is there and I'm very happy with it :) lli should now be able to execute the output from llvm-gcc when using exceptions (the UnwindInst instruction is not involved in this patch). Just add the

Hi Evan, Evan Cheng wrote: > > I don't think the duplication is going to be top much of a problem. If > it is, I'll bug you about refactoring. :) > > I don't mean to show how lazy I can be, but I also need to know the size of the exception table emitted in memory (JITDwarfEmitter.cpp). Reviewing it a little, I can not see how things won't be duplicated.