search for: endgoal

...LLVM GC (static stack maps) is a significant performance improvement—but it absolutely does require support from the code generator. Return addresses must be mapped to stack maps, and only the code generator knows where return addresses lie and how the stack frame is laid out. The ultimate endgoal is to support schemes with still-lower execution overhead. The next step for LLVM GC would be elimination of the reload penalty for using GC intrinsics with a copying collector. This, again, requires that the code generator perform bookkeeping for GC pointers. On Feb 27, 2009, at 06:38, Mark...

Hi, I realise this might be a bit controversial ;) Suppose I am writing a VM (such as VMKit), or a VM toolkit, and I want to add a generational GC. If I want to use the llvm.gcwrite intrinsic for my write barrier then I need to write a GC and then implement for each and *every* backend the gcwrite intrinsic for my write barrier. Now, if I don't use the intrinsic, I need to write my write

...the optimisation passes that certain memory locations may be moved. But information about stack layout is useful for things other than GC and would be useful for interactive debugging as well. Intrinsics should be named for their function, not for their presumed usage. > > The ultimate endgoal is to support schemes with still-lower execution > overhead. The next step for LLVM GC would be elimination of the reload > penalty for using GC intrinsics with a copying collector. This, again, > requires that the code generator perform bookkeeping for GC pointers. Elimination of t...

On Feb 27, 2009, at 12:56, Mark Shannon wrote: > Gordon Henriksen wrote: > >> The ultimate endgoal is to support schemes with still-lower >> execution overhead. The next step for LLVM GC would be elimination >> of the reload penalty for using GC intrinsics with a copying >> collector. This, again, requires that the code generator perform >> bookkeeping for GC poin...

On Thu, Nov 7, 2019 at 3:09 AM Roman Lebedev via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Strong -1 personally. Likewise, for many of the same reasons detailed below. ~Aaron > * What is the endgoal? To fully kill phab and move to github pullrequests? > it might be best to discuss *that* first. (did i miss an RFC?) > * Separation of attention - does everyone who cares > now has to also look at pull requests for reviews; > or should they be exempt from general review attention...

Mark Shannon wrote: > Jon Harrop wrote: >> On Thursday 26 February 2009 17:25:56 Chris Lattner wrote: >>> In my ideal world, this would be: >>> >>> 1. Subsystems [with clean interfaces] for thread management, >>> finalization, object model interactions, etc. >>> 2. Within different high-level designs (e.g. copying, mark/sweep, etc) >>>

...t of good points regarding other, more bureaucratic aspects of GitHub and it raising the bar for existing contributors. Just my two cents in. On Thu, Nov 7, 2019 at 8:09 AM Roman Lebedev via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Strong -1 personally. > > * What is the endgoal? To fully kill phab and move to github pullrequests? > it might be best to discuss *that* first. (did i miss an RFC?) > * Separation of attention - does everyone who cares > now has to also look at pull requests for reviews; > or should they be exempt from general review attention...

FWIW I'm a fan of using open-source stuff for open-source projects. Discourse looks open source, but Discord doesn't as far as I can tell (?). On Mon, Nov 18, 2019 at 3:15 AM Chandler Carruth via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Hello folks, > > I sent the message quoted below to llvm-dev@ just now, but it applies to > the whole community so sending an FYI

...:llvm-dev at lists.llvm.org>> wrote: On Thu, Nov 7, 2019 at 3:09 AM Roman Lebedev via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: > > Strong -1 personally. Likewise, for many of the same reasons detailed below. ~Aaron > * What is the endgoal? To fully kill phab and move to github pullrequests? > it might be best to discuss *that* first. (did i miss an RFC?) > * Separation of attention - does everyone who cares > now has to also look at pull requests for reviews; > or should they be exempt from general review attention...

...hat, > feels like ICQ/Skype all over again), centralization, etc; are pretty > 'major' regressions. > > As a general, not really LLVM-specific remark, > I find it worrying that the noble goal of usability improvement/entry > barrier lowering is being applied with only said endgoal in mind > and no real assessment of the approach taken, the effect produced > by such approach and the cost it incurs on the existing > ecosystem/community/etc. > But this is very much the norm in nowadays world :/ > > > Roman. > > > On Mon, Nov 18, 2019 at 3:15 AM Cha...

...Roman Lebedev via llvm-dev >>> <llvm-dev at lists.llvm.org> wrote: >>> > >>> > Strong -1 personally. >>> >>> Likewise, for many of the same reasons detailed below. >>> >>> ~Aaron >>> >>> > * What is the endgoal? To fully kill phab and move to github >>> pullrequests? >>> > it might be best to discuss *that* first. (did i miss an RFC?) >>> > * Separation of attention - does everyone who cares >>> > now has to also look at pull requests for reviews; >>&...

Hi all, Now that we're on GitHub, we can discuss about pull-requests. I'd like to propose to enable pull-request on GitHub, as a first step as an experimental channel alongside the existing methods for contributing to LLVM. This would allow to find workflow issues and address them, and also LLVM contributors in general to start getting familiar with pull-requests without committing to

...>> <llvm-dev at lists.llvm.org> wrote: >>>> > >>>> > Strong -1 personally. >>>> >>>> Likewise, for many of the same reasons detailed below. >>>> >>>> ~Aaron >>>> >>>> > * What is the endgoal? To fully kill phab and move to github >>>> pullrequests? >>>> > it might be best to discuss *that* first. (did i miss an RFC?) >>>> > * Separation of attention - does everyone who cares >>>> > now has to also look at pull requests for re...