similar to: [LLVMdev] GSoC 2009: Extending LLVM IR to aid multi-core code generation

Hi Milos, Milos Puzovic wrote: > Hi, > > I would like to extend LLVM IR with two new intrinsic: spawn and join. > The spawn intrinsic will indicate that the call it modifies can safely > run in parallel, while join intrinsic will indicate that the execution > of the current call cannot continue until all previously spawned calls > in the list/array passed as argument to

Hi Nicolas, 2009/3/30 Nicolas Geoffray <nicolas.geoffray at lip6.fr> > Can you be more verbose on this? Are you planning to implement some JVM > or .Net extension for supporting your new intrinsics? Or are you just > looking for a runtime with a GC? At the moment I am not looking to add any new extensions to JVM or .NET. I would need a runtime with a GC to demonstrate and test

Can you not achieve the same effect without adding intrinsics? Insert function calls to a __spawn and __join pseudo-function instead? 2009/3/30 Milos Puzovic <milos.puzovic at gmail.com> > Hi Nicolas, > > 2009/3/30 Nicolas Geoffray <nicolas.geoffray at lip6.fr> > >> Can you be more verbose on this? Are you planning to implement some JVM >> or .Net extension

The reason for my suggestion is that adding intrinsics is also considered to be a breaking change. This is the third question/suggestion in the last week or so where the intrinsics/pseudo-function idea has been raised. Perhaps what llvm really needs is a 'generic' pseudo-intrinsic of some kind? 2009/3/30 Milos Puzovic <milos.puzovic at gmail.com> > 2009/3/30 someguy

Hi Anthony, 2009/3/30 Anthony Danalis <adanalis at eecs.utk.edu> > Is the user expected to add the calls to spawn/join or the compiler? If > it's the compiler adding them, then you don't need to change the front-end > at all, you can do all that in an optimization pass. If it's the user > adding them, then adding calls to "__spawn()" that the compiler

2009/3/30 someguy <just.s0m3.guy+llvmdev at gmail.com<just.s0m3.guy%2Bllvmdev at gmail.com> > > Can you not achieve the same effect without adding intrinsics? Insert > function calls to a __spawn and __join pseudo-function instead? > It would make LLVM code generation more difficult because instead of building a new instruction (in this case intrinsic) you will be building

Just to add 2 comments to this discussion: -- Hans Boehm had an excellent paper in PLDI a few years arguing why "threads cannot be a library." (Google for that phrase.) This is a fundamental problem with compiler optimizations for code that uses libraries like pthreads. This argues in favor of having explicit support in the IR. -- On the other hand, explicitly parallel

I think your idea is very interesting. However, some of the issues that concern you might not be as bad as you think. On Mar 30, 2009, at 9:19 AM, Milos Puzovic wrote: > 2009/3/30 someguy <just.s0m3.guy+llvmdev at gmail.com> > Can you not achieve the same effect without adding intrinsics? > Insert function calls to a __spawn and __join pseudo-function instead? > It would

Thanks a lot. A see the shared library in linux version. I initially tried doing this in cygwin where I dont see the shared library being built. Do u think it could have been cygwin that is the problem? Aparna On Mon, Apr 13, 2009 at 5:16 PM, Milos Puzovic <milos.puzovic at gmail.com>wrote: > In order to generate shared libraries you need to have SHARED_LIBRARY > and

I believe because cygwin behaves like windows (it is just a posix layer over window) it doesn't have dynamic linking hence only static libraries have been built. On 13 Apr 2009, at 23:16, aparna kotha wrote: > Thanks a lot. > > A see the shared library in linux version. I initially tried doing > this in cygwin where I dont see the shared library being built. Do > u

When virtio-blk device is resized from host (using block_resize from QEMU) emit KOBJ_CHANGE uevent to notify guest about such change. This allows user to have custom udev rules which would take whatever action if such event occurs. As a proof of concept I've created simple udev rule that automatically resize filesystem on virtio-blk device. ACTION=="change", KERNEL=="vd*",

When virtio-blk device is resized from host (using block_resize from QEMU) emit KOBJ_CHANGE uevent to notify guest about such change. This allows user to have custom udev rules which would take whatever action if such event occurs. As a proof of concept I've created simple udev rule that automatically resize filesystem on virtio-blk device. ACTION=="change", KERNEL=="vd*",

2009/12/10 Milos Blazevic <milosb at list-solutions.com> > > Hi Ralph, > > I'm a member of CentOS forum and I've tracked problems laptop users are having with Broadcom's wireless hardware (namely, the one(s) in the subject). > Under the circumstances, I had to install one of these myself back in August, which I did - after doing some googleing. Shortly after,

Hi, I have 3 tables with HABTM relation. USERS -> QUOTE_TO_USER <- QUOTES Table QUOTE_TO_USER has 3 attributes: quote_id, user_id, component. I have a form where I can tie multiple users to QUOTE. This is easy one, thru "user_ids" (@quote[:user_ids] = @params[:quote][:user_ids]). In this form I have all users and I just check those I want to tie to this quote, however

Hi Eric, Could you explain the intent and policy regarding the test-suite body of code. Should the test be left as much as possible as-is (even if technically incorrect)? Should changes only affect the XCore target (#ifdef) or should all targets get the changes? Taking "int32_t main" as an example. The correct return type & argc for main is 'int'. In the XCore tool chain,

... and so (I infer from that) it should not be patched let alone need any changes. Assuming my inference is correct, any patching should only affect the XCore target and only if there is a good reason why the XCore requires the change. So, is #ifdef around all/most changes the correct way to submit a patch? Robert ________________________________ From: Eric Christopher [echristo at gmail.com]

In order to generate shared libraries you need to have SHARED_LIBRARY and LOADABLE_MODULE defined in the Makefile. See here for more details: http://llvm.org/docs/MakefileGuide.html#libraries On 13 Apr 2009, at 20:46, aparna kotha wrote: > I am trying to run the LLVM hello world pass. I observe that in the > OUPUT_DIR/lib the LLVMHello.a and LLVMHello.la libraries are >

Hi, I have found it necessary to make some changes to the test-suite for the XCore platform. These changes include: altering #includes, as supported by XCore; using stdout or stderr to make the output diffs consistent (fixing expected output too); (This work is still under review as best way to do it) 'fixing' symbol and type problems e.g name clashes & scope;

We would like to migrate grom Winnt 4.0 to Samba 3 with ldap support. We have installed openldap on Rh 2.1 AS and created starting databases with IDEALX.org scripts. Now i have added computer to domain no problems and than I tried to migrate users and groups, but only user migrate but there is a problem " Primary group of Administrator has no mapping!" ( this is error for every user).

Hi, As a consequence of rolling out CR updates on Latitude E7470 (Skylake chipset), X would no longer start until I rolled back all of the xorg-\* packages. And to be more precise, looks like the culprit is xorg-x11-drv-intel: https://bugzilla.redhat.com/show_bug.cgi?id=1445583 as the CR package release version matches the one mentioned in Comment #2, in the regression context.