similar to: [LLVMdev] Question about SparseMultiSet

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

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

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

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

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

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

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

Why not just run the c preprocessor before running tablegen? Micah > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Jeroen Dobbelaere > Sent: Wednesday, August 07, 2013 1:33 AM > To: llvmdev at cs.uiuc.edu > Subject: [LLVMdev] tablegen question > > Hi, > > I am trying to make my tablegen

On 08/08/2013 02:52 PM, Micah Villmow wrote: > This is something I proposed last year, so you might want to read up on that discussion first. > > You can find it here: > http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-September/053277.html Uhm... I read the discussion, probably I've not understood the problem well: the conclusion (it has been committed?) is that to handle address

Chandler brought up removing it back in February but Rogelio Serrano said he could maintain it and Jeff Fifield from Xilinx was supposed to check if someone could help. If no one has stepped up in the past 5 months, then I don't see an issue with removing it. Micah > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On

Antony, What are you trying to accomplish in this case? I did something very similar in the AMDIL backend, but it was not the cleanest solution and you are correct it has to be do at doInitialization stage and not at runOnMachineFunction. Micah > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Antony Yu > Sent:

I think the database got corrupted again, only shows 4 people showing up, but there were quite a few more last week. Micah From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Nick Lewycky Sent: Tuesday, July 09, 2013 10:39 AM To: LLVM Developers Mailing List; clang-dev Developers Subject: Re: [LLVMdev] llvm bay-area social in july On 24 June 2013 18:58,