similar to: [LLVMdev] is there some canonical way to extend liveness?

[+CC llvm-dev this time] Hi, As discussed in the review thread in http://reviews.llvm.org/D16439, the future plan around statepoints, deopt bundles, PlaceSafepoints etc. is to "constant fold" -spp-no-statepoints and -rs4gc-use-deopt-bundles to true. We (Azul) have moved to a representation of safepoint polls, deopt state etc. that enables us to do the above; and at this point I'm

Inline. From: Philip Reames [mailto:listmail at philipreames.com] Sent: Thursday, August 27, 2015 11:01 AM To: Swaroop Sridhar <Swaroop.Sridhar at microsoft.com>; llvm-dev <llvm-dev at lists.llvm.org>; Sanjoy Das <sanjoy at playingwithpointers.com> Cc: Joseph Tremoulet <jotrem at microsoft.com>; Andy Ayers <andya at microsoft.com>; Russell Hadley <rhadley at

I recall it was things we could deduce by scanning the method before we optimized it, eg deduced noreturn/nothrow. I'd have to go check to be sure. Once you allow inlining, you're pretty much telling your users they had better give you compatible definitions. We wanted to make sure that if users gave us compatible defs (mainly: same source, but optimized in one CU and not in another),

> On Feb 25, 2016, at 12:02 PM, Andy Ayers via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I recall it was things we could deduce by scanning the method before we optimized it, eg deduced noreturn/nothrow. I'd have to go check to be sure. Yes, my understanding is that this is what Chandler suggested when he wrote as part of his plan: 2) Teach frontends to emit (even at

I'm probably missing something obvious here, but naively, this makes it kind of awkward to have mutable thread local state... -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141212/53b577ae/attachment.html>

On Thu, Dec 17, 2015 at 9:21 AM, Andy Ayers <andya at microsoft.com> wrote: > While your bb count distribution is extremely likely to be some kind of power-law like distribution, it's not guaranteed. > > Also you might think about operations that can amplify (rerolling) or appear to amplify (TRE) or diminish BB counts, and how you'd go about reclassifying block hotness. yes

On Thu, Feb 25, 2016 at 11:27 AM, Andy Ayers <andya at microsoft.com> wrote: > For non-LTO compiles: block bottom-up propagation of facts that > depend on optimization levels -- eg register kills and parameter usage > summaries. Allow other IP information to flow upwards, since at least > in our world all comdat-foldable definitions are supposed to be > "equivalent".

On Wed, Dec 16, 2015 at 6:00 PM, Andy Ayers <andya at microsoft.com> wrote: > I’ve done similar rankings with profile data and found it worked out pretty > well. > > > > In my case it was ranking function hotness but the idea was similar: sort by > weight, compute various percentile cutoff points, and use those to classify. > I put in some compensation for truly

Thanks Andy, helpful as always! 1 is a possibility, but not ideal for us. Could you elaborate a little on 3? I don't really know what a jump stub is, but am guessing it's a kind of "alternative symbol" which would just act as a middle man to invoke the "real" symbol in the static library. If that's the case, I can think of a way to implement it for specific

A couple things I recall from implementing this in Phoenix: For LTO -- do your comdat folding as part of the up-front symbol resolution before invoking the backend (saves compile time too). Then have the linker ensure that the comdat from the LTO bundle is the winner in the final link step. That way during LTO you know which method body is going to be in the final image. May not be as easy in

Philip: I think there are two separate issues: 1) Handling GC pointers stored in stack locations -- tracking their liveness, reporting them to the GC. etc. 2) Treating pointers to stack locations as GC-pointers. I think the two options that you presented here are for solving (1). I'm trying to solve issue (2) using alloca in addrspace(1). Basically, we want to create a pointer to a stack

The LLILC project does not require direct interaction with the PDB, so it’s not part of our plans. The JIT uses a special reporting format to communicate debug info (frame info and machine->IL mappings) back to the CoreCLR EE. The debugger joins this with the frontend-produced debug information (IL->source and logical frame offset->local, which is in a PDB) to complete the picture.

Function has its own FunctionType* member as well as a Type* member that it inherits from GlobalValue. The latter can be mutated but not the former, leading to potential strange inconsistencies. While I realize using mutateType is probably going to trigger a bunch of "you're doing it wrong" replies, it seems like mutateType, as a necessary evil, should be virtual and do the right

Hi Team, I'm working on a new pure functional language and I'm trying to add GC support for that. Because all vars are immutable, the IR that my frontend generates are all register based, i.e. no alloca, and no readmem, writemem unless accessing/constructing structs. If I use the traditional GC with gcroot intrinsic, it will need to emit more code for liveness tracking, storing the IR

> -----Original Message----- > From: Philip Reames [mailto:listmail at philipreames.com] > Sent: Friday, August 28, 2015 9:38 AM > To: Swaroop Sridhar <Swaroop.Sridhar at microsoft.com>; llvm-dev <llvm- > dev at lists.llvm.org>; Sanjoy Das <sanjoy at playingwithpointers.com> > Cc: Joseph Tremoulet <jotrem at microsoft.com>; Andy Ayers > <andya at

Thanks for reviving this. I completely forgot the details but I resolved this problem. Looking though the code, seems I forked RewriteStatepointsForGC pass, and change it to adding 'gc-livevars' bundle to the call/invoke inst after finding the livevars, instead of changing it to StatepointCall intrinsic. On Wed, Nov 14, 2018 at 11:48 AM Philip Reames <listmail at philipreames.com>

Thanks for the pointer, it's always helpful to be able to see how another project solved similar problems. > On Mar 8, 2016, at 11:24 AM, Andy Ayers <andya at microsoft.com> wrote: > > FWIW, LLILC (https://github.com/dotnet/llilc) uses MCJIT with a custom memory manager to hold onto the binary bits and discard the rest. > > As far as I know it doesn't leak, though

First of all, thanks very much to Lang for fixing the BSS section bug; works like a charm! I’ve been unable to reproduce the 32 bit relocation on 64 bit code (I’ll let you know if I do). However, I’m still having issues with resolving the 64 bit symbol relocations. In case it’s relevant, the specific symbol my program is tripping up on is IID_IOleObject, where TargetAddress is dereferenced

That's great news, thanks! If I can be of any help, let me know. :) I'll see if I can reduce the example for the relocation issue whilst you're at it. Regards, Joshua -- Joshua Gerrard JUCE Software Developer *ROLI’s **award-winning* <http://www.telegraph.co.uk/luxury/design/31520/the-seaboard-grand-piano-wins-designs-of-the-year-2014-award.html>* Seaboard GRAND, celebrated

Is anyone aware of an existing framework for asking liveness questions about SSA values in the IR? I'm looking for something more precise than the trivial definition provided by SSA itself. I can write something myself (and will if need be), but it seemed like a generic enough problem that I was surprised I couldn't find something already in tree. Anyone know of something I've