similar to: [LLVMdev] std::vector usage in Machine* data types

On Nov 19, 2013, at 10:52, Micah Villmow <micah.villmow at smachines.com> wrote: > +llvm-dev > Yes. The question then becomes, does LLVM handle the case where the cast of the value 0 to a non-void* pointer? > > Think of this case: > int *ptr = (int*)0; > > based on a strict reading of the spec, ptr itself technically is not the null pointer constant. Not true, the

Does anyone know if an insertion invalidates the end() iterator? The documentation in ADT/SparseMultiSet.h mentions that removal only invalidates the iterator of the object being removed, but nothing on insertion. My understanding from reading the code seems to me that it doesn't invalidate it, but I want to make sure as I'm not 100% sure here. Thanks, Micah -------------- next part

Hi Micah, Thanks a lot for the reference. Unfortunately, it looks like the discussion there is dealing with a somewhat different issue - modeling OpenCL address spaces. It's true that the null pointer issue may arise in a similar context (e.g. null pointers in different address spaces may have different internal representations), but it's not entirely related. Or have I missed something

Micah, As you expected, I am trying to create local memory but in the NVPTX backend. It's really not convenient that I can't create local memory in runOnMachineFunction. Hmm.... Since I should do it at doInitialization stage, I also need to do some tricks in global variable and AsmPrinter to resize it. Did you use the similar way? Antony 2013/8/5 Micah Villmow <micah.villmow at

Sorry for the late reply. On Jul 26, 2013, at 3:26 PM, Micah Villmow <micah.villmow at smachines.com> wrote: > Does anyone know if an insertion invalidates the end() iterator? The documentation in ADT/SparseMultiSet.h mentions that removal only invalidates the iterator of the object being removed, but nothing on insertion. My understanding from reading the code seems to me that it

On Thu, Jun 27, 2013 at 12:49 PM, Micah Villmow <micah.villmow at smachines.com > wrote: > That said, changes of this magnitude should be done in a branch instead of > mainline trunk. I strongly disagree. If you think this is the case, we should probably start a new thread (rather than ressurecting this one) with the context of what you want to do and why you think it should be on a

The reason why I say it should be done in a separate branch is that the final design is not necessarily the same as the first initial implementation. There are things that will break and this kind of change touches almost everything, not just the core LLVM libraries. It is hard to get right the first time, and developing it in a sandbox will dramatically decrease the amount of churn that will show

+llvm-dev Yes. The question then becomes, does LLVM handle the case where the cast of the value 0 to a non-void* pointer? Think of this case: int *ptr = (int*)0; based on a strict reading of the spec, ptr itself technically is not the null pointer constant. If ptr points to an object in the local address space in OpenCL, or any address space where 0 is a valid address and memory exists, does

Outside of what was listed below, which you would have to go back into the other emails/reviews to get into more details, I believe the handling of global constants expressions was problematic with the API's that I had implemented. That said, changes of this magnitude should be done in a branch instead of mainline trunk. Micah -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu

This isn't by itself too difficult, as I have done something similar recently, but does require some modifications of LLVM. The basic algorithm is simple: For each ISA instruction, create a new MachineInstr and add it to the current MachineBasicBlock. At each branch instruction, add it to the current MBB and add it to a list and create a new MBB. After creating your list of MBB, iterate

On Aug 8, 2013, at 7:22 , Micah Villmow <micah.villmow at smachines.com> wrote: > It was commited at one point, however due to personal matters, I was not able to respond to issue that arose and the changes were reverted. > The longer explanation for why it was reverted can be read here: > http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-November/055098.html Actually you never

After a bunch more investigate, I've seem to have figured out what is going on here. The MachineFunction holds a vector of MachineBasicBlocks and it is this vector that is traversed by the MachineFunction iterator when printing out instructions. The problem is occurring when a modification to the CFG moves around so that the ordering of them is different. Even if the pred/succ blocks are

I used the A9 schedule as an example: http://llvm.org/svn/llvm-project/llvm/trunk/lib/Target/ARM/ARMScheduleA9.td The documentation could use more clarity, but this is how I was able to do it to always get two specific instructions to be scheduled together. ________________________________________ From: reed kotler [rkotler at mips.com] Sent: Tuesday, September 17, 2013 8:54 PM To: Micah Villmow

Micah, Thanks for your help. I will study on that code. Justin, Sorry for my misleading word. Local memory in OpenCL is the same as share memory in CUDA. What I mean is share memory, so MachineFrameInfo is not suitable to me. And I need codegen data, so FunctionPass is also not suitable. Anyway, thanks for the suggestion. Antony 2013/8/5 Justin Holewinski <justin.holewinski at

Chris, I took a look at AnalyzeBranch and I don't see how it can solve my problem. The issue itself isn't with branching, as I can handle branches fairly well in my custom pass(see the before and after dot files attached). I can take a bunch of branches and construct high level control flow for my backend since I have no ability to do goto/jump, only whileloop and ifs. So analyzing the

That doesn't actually give you a guarantee that they won't be split up. Phases other than the scheduler may insert instructions in the middle of block (constant island pass, for example). Pseudo-instructions are the canonical answer to that problem. --Owen On Sep 17, 2013, at 11:09 PM, Micah Villmow <micah.villmow at smachines.com> wrote: > I used the A9 schedule as an

I am currently attempting to learn how to use LLVM for control flow graph extraction on linux (Ubuntu). Basically, I need to be able to break down specific basic functions blocks from assembly code, and use it to make a CFG. Do any of you upstanding human beings have any knowledge or resources that could possibly assist me in this task? I apologize if this is a very basic question. I have already

It was commited at one point, however due to personal matters, I was not able to respond to issue that arose and the changes were reverted. The longer explanation for why it was reverted can be read here: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-November/055098.html Micah > -----Original Message----- > From: Michele Scandale [mailto:michele.scandale at gmail.com] > Sent:

I want to create share memory in my MachineFunctionPass, and insert load/store instruction for it. The way to create share memory is to add global variables which are in share memory address space (not sure if it is the only way). Therefore, I should add global variables in fixed size in doInitialization, and record its real size in other place like MachineModuleInfo. Then modify or query its real

If you're running a MachineFunctionPass, then the code has already been lowered to machine instructions and modifying the original IR will most likely not do what you want. You should only be using the IR as an immutable object for reference. If you want to change the IR, I would suggest using a FunctionPass instead of a MachineFunctionPass. Unless you need codegen data. At the