similar to: [LLVMdev] unsubscribe

+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

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

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

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

Hi Timur, I myself find the name "Win32" pretty confusing and easy to misuse (especially for someone who assumes that windows == msvc). After all mingw and cygwin is also win32. Maybe we should rename it into isTargetMSVC or something like this? On Wed, Mar 27, 2013 at 6:26 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > Anton, > > What do you think? > >

Hi Anton, >From my perspective Win32 is the windows ABI and mingw and cygwin are their own ABIs especially as we're not targeting the MSVC abi, it's just the windows abi? -eric On Wed, Mar 27, 2013 at 1:32 PM, Anton Korobeynikov <asl at math.spbu.ru>wrote: > Hi Timur, > > I myself find the name "Win32" pretty confusing and easy to misuse > (especially

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

2013/11/21 Eric Christopher <echristo at gmail.com> > On Wed, Nov 20, 2013 at 9:46 AM, Timur Iskhodzhanov <timurrrr at google.com> > wrote: > > Eric, David, > > > > 2013/11/19 Timur Iskhodzhanov <timurrrr at google.com>: > >> Attached is a slightly updated patch. > >> (it doesn't include D2222 yet). > > > > The new

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

On Tue, Dec 3, 2013 at 11:04 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > > > > 2013/12/3 Eric Christopher <echristo at gmail.com> >> >> >> > >> >> >> >> Probably the same structure that we've been going down via >> >> lib/DebugInfo/. A set of files than handle reading and parsing and >> >>

Anton, What do you think? 2013/3/20 Eric Christopher <echristo at gmail.com>: > > > > On Wed, Mar 20, 2013 at 5:21 PM, Timur Iskhodzhanov <timurrrr at google.com> > wrote: >> >> 2013/3/20 Timur Iskhodzhanov <timurrrr at google.com>: >> > Anton, >> > >> > [+Eric, Nick, >> > the e-mail thread context has been broken a

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 still think there is a bug somewhere, but not sure where yet. This is what is generated in intrinsic.gen: case Intrinsic::opencl_math_fdistance: // llvm.opencl.math.fdistance ResultTy = Type::FloatTy; ArgTys.push_back(Tys[0]); ArgTys.push_back(Tys[0]); break; This is the intrinsic definition: def int_opencl_math_fdistance_fast : Intrinsic<[llvm_float_ty],

On Wed, Nov 20, 2013 at 9:46 AM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > Eric, David, > > 2013/11/19 Timur Iskhodzhanov <timurrrr at google.com>: >> Attached is a slightly updated patch. >> (it doesn't include D2222 yet). > > The new version of the patch stopped fitting into the llvmdev 100K limit, > so I've uploaded it to

2013/12/3 Eric Christopher <echristo at gmail.com> > >> > > >> > >> Probably the same structure that we've been going down via > >> lib/DebugInfo/. A set of files than handle reading and parsing and > >> both some binary files and some files produced by the backend. > > > > > > Ooph, that's a big one. > > Any

On Wed, Mar 20, 2013 at 5:21 PM, Timur Iskhodzhanov <timurrrr at google.com>wrote: > 2013/3/20 Timur Iskhodzhanov <timurrrr at google.com>: > > Anton, > > > > [+Eric, Nick, > > the e-mail thread context has been broken a few times, so you should > > probably look at the llvmdev archives. > > It all starts here: > >

On Tue, Oct 2, 2012 at 8:44 PM, Anton Korobeynikov <asl at math.spbu.ru> wrote: >>>> b) Should I be altering CC_X86_32_ThisCall >>>> OR should I introduce CC_X86_Win32_ThisCall instead? >>>> [Answer not clear to me - is there any platform besides Windows >>>> that uses thiscall?] >>> no >> Can you please clarify which

On Thu, Oct 23, 2014 at 2:46 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: > 2014-10-23 11:34 GMT-07:00 Aaron Ballman <aaron at aaronballman.com>: >> On Thu, Oct 23, 2014 at 2:24 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: >>> I don't think this is the right approach. >>> >>> Currently we intentionally define malloc etc

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