search for: tremoulet

...listened for when an object is emitted (NotifyObjectEmitted), and that’s when we’d go through and extract debug info from the ObjectFile. Now, I imagine I’d need to add some sort of layer, I’m just not sure when, where or how to get that set up, and am looking for some guidance on it. From: Joseph Tremoulet Sent: Thursday, June 4, 2015 11:29 AM To: Michelle McDaniel; Lang Hames Cc: llvmdev at cs.uiuc.edu Subject: RE: [LLVMdev] MCJit interface question Which events do you need to listen to? The ObjectLinkingLayer that we're using has notifications when an object is loaded and when it is finalized...

...Orc to do the sorts of things that the JITEventListeners do in MCJIT? How would I go about adding a layer to add debugging support? Thanks, Michelle From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Lang Hames Sent: Monday, June 1, 2015 10:41 AM To: Joseph Tremoulet Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] MCJit interface question Hi Russell, Joseph, > I'll look into moving LLILC to ORC. Sounds good. Please let me know how your experiments go. I'm keen to improve the Orc APIs further, so your feedback would be very welcome. Cheers, Lan...

----- Original Message ----- > From: "Vaivaswatha Nagaraj" <vn at compilertree.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Joseph Tremoulet" <jotrem at microsoft.com>, "llvm-dev" > <llvm-dev at lists.llvm.org> > Sent: Sunday, December 13, 2015 9:50:25 PM > Subject: Re: [llvm-dev] RFC: New function attribute > HasInaccessibleState > >I'm against adding this as a "subtractive" a...

Agreed, that sounds like the best plan. I'll look into moving LLILC to ORC. Thanks -Joseph From: Russell Hadley Sent: Friday, May 29, 2015 8:13 PM To: Lang Hames; Joseph Tremoulet Cc: llvmdev at cs.uiuc.edu Subject: RE: [LLVMdev] MCJit interface question Hey Joseph, What Lang said made me wonder. Is it the right time for us (LLILC) to move to ORC? The long term plan was to go there but this could be our forcing function. -R From: llvmdev-bounces at cs.uiuc.edu<mailt...

...id made me wonder. Is it the right time for us (LLILC) to move to ORC? The long term plan was to go there but this could be our forcing function. -R From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Lang Hames Sent: Friday, May 29, 2015 2:23 PM To: Joseph Tremoulet Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] MCJit interface question Hi Joseph, There are several reasons that a client might want to access the object before it's loaded, so a general API like #2 seems like the way to go. To support this in MCJIT you can add this to the event listener...

----- Original Message ----- > From: "Joseph Tremoulet" <jotrem at microsoft.com> > To: "Hal Finkel" <hfinkel at anl.gov>, "Mehdi Amini" <mehdi.amini at apple.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Friday, December 11, 2015 3:35:38 PM > Subject: RE: [llvm-dev] RF...

----- Original Message ----- > From: "Mehdi Amini" <mehdi.amini at apple.com> > To: "Joseph Tremoulet" <jotrem at microsoft.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Friday, December 11, 2015 1:28:05 PM > Subject: Re: [llvm-dev] RFC: New function attribute HasInaccessibleState > > > &g...

...14, 2015 at 1:36 PM, Hal Finkel <hfinkel at anl.gov> wrote: > >> ----- Original Message ----- >> >> > From: "Vaivaswatha Nagaraj" <vn at compilertree.com> >> > To: "Hal Finkel" <hfinkel at anl.gov> >> > Cc: "Joseph Tremoulet" <jotrem at microsoft.com>, "llvm-dev" >> > <llvm-dev at lists.llvm.org> >> > Sent: Sunday, December 13, 2015 9:50:25 PM >> > Subject: Re: [llvm-dev] RFC: New function attribute >> > HasInaccessibleState >> >> > >I'...

...mented somewhere? For a concrete example, consider your snippet showing what the IR would look like after outlining with #3. What's to stop a later pass from redoing the hoist? Thanks -Joseph From: Reid Kleckner [mailto:rnk at google.com] Sent: Thursday, February 12, 2015 6:10 PM To: Joseph Tremoulet Cc: Kaylor, Andrew; Bataev, Alexey; Reid Kleckner (reid at kleckner.net); LLVM Developers Mailing List Subject: Re: [LLVMdev] RFC: Native Windows C++ exception handling You're right, we would hoist the add to someplace before the notional indirectbr, but that needs to work anyway. After lookin...

...pass might try to insert code into that block? Like maybe some sort of late profile instrumentation? It's great if there's not; I'm just trying to understand why not. Thanks -Joseph From: Reid Kleckner [mailto:rnk at google.com] Sent: Wednesday, February 11, 2015 5:09 PM To: Joseph Tremoulet Cc: Kaylor, Andrew; Bataev, Alexey; Reid Kleckner (reid at kleckner.net); LLVM Developers Mailing List Subject: Re: [LLVMdev] RFC: Native Windows C++ exception handling On Wed, Feb 11, 2015 at 1:57 PM, Joseph Tremoulet <jotrem at microsoft.com<mailto:jotrem at microsoft.com>> wrote: Ah...

...and I2 have multiple outgoing indirect edges), we could redirect A to D0A; but because I1 and I2 both need to indirectly jump to D, we couldn't give them their own "copies" of D (i.e., D0B and D0C). Is my understanding correct? Thanks, -Stefan On Wed, Nov 6, 2019 at 12:23 PM Joseph Tremoulet <jotrem at microsoft.com> wrote: > What the comment doesn’t specify, but the code implements, is that “D0B” > is the original block “D” (after copying/moving various things out of it as > described). That’s important because there’s code in the IR somewhere that > gets the addre...

...wind label would go here if there were an action The endcleanup instruction would use 'to' and 'unwind' label operands to mirror the structure of an invoke. In fact, endcleanup is almost nicer than 'unwind'. Maybe we should use that. On Tue, May 19, 2015 at 7:19 PM, Joseph Tremoulet <jotrem at microsoft.com> wrote: > > Most passes would see the cleanupblock instruction and run the other > way > > 1) That statement surprises me. I would have expected the cleanupblock > instruction to look pretty benign; it doesn't have any side-effects, does >...

...- Sanjoy > > Thanks, > > > - Vaivaswatha > > On Sat, Dec 12, 2015 at 3:21 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > ----- Original Message ----- > > From: "Joseph Tremoulet" <jotrem at microsoft.com <mailto:jotrem at microsoft.com>> > > To: "Hal Finkel" <hfinkel at anl.gov <mailto:hfinkel at anl.gov>>, "Mehdi Amini" <mehdi.amini at apple.com > <mailto:mehdi.amini at apple.com>> >...

...er should not generate code like that. Thanks, --Ten From: Eli Friedman <efriedma at quicinc.com> Sent: Thursday, April 16, 2020 2:10 AM To: Ten Tzen <tentzen at microsoft.com>; llvm-dev at lists.llvm.org Cc: rnk at google.com; Aaron Smith <aaron.smith at microsoft.com>; Joseph Tremoulet <jotrem at microsoft.com> Subject: [EXTERNAL] RE: [RFC] [Windows SEH][-EHa] Support Hardware Exception Handling From: Ten Tzen <tentzen at microsoft.com<mailto:tentzen at microsoft.com>> Sent: Wednesday, April 15, 2020 9:15 PM To: Eli Friedman <efriedma at quicinc.com<mai...

...token type, I think you'll want to look at the handling of the @llvm.eh.exceptionpointer intrinsic that's used with catchpads and basically do the same thing with landingpads. Thanks -Joseph From: Chen Li [mailto:meloli87 at gmail.com] Sent: Saturday, December 5, 2015 12:34 AM To: Joseph Tremoulet <jotrem at microsoft.com> Cc: David Majnemer <david.majnemer at gmail.com>; Igor Laevsky <igor at azulsystems.com>; llvm-dev <llvm-dev at lists.llvm.org>; John McCall <rjmccall at apple.com> Subject: Re: Support token type in struct for landingpad On Dec 4, 2015, at...

...ssing the frame pointer, it would pass the address of each escaped local variable. If the cleanup is simple, it'll be inlined and some locals may be eliminated, and if not, the outlined funclet will only contain a single call with lots of lea+push pairs. On Tue, May 19, 2015 at 2:22 PM, Joseph Tremoulet <jotrem at microsoft.com> wrote: > > teach the inliner how to undo framerecover and let the optimization > fall out that way > > You'd still have the problem that the referenced variables were > frameescaped and appear to be read/written at unrelated calls. > > &...

On 2 Sep 2015, at 02:54, Joseph Tremoulet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Reading further, I see both that addrspacecast "can be a no-op cast or a complex value modification"[2] and that bitcast "may only be [used on pointers] with the same address space"[4]. > > So I'm getti...

...might want to merge the adds by hoisting them up above the indirect branch? If that happened, wouldn't it get skipped over if an exception were raised? Thanks -Joseph From: Kaylor, Andrew [mailto:andrew.kaylor at intel.com] Sent: Wednesday, February 11, 2015 2:06 PM To: Reid Kleckner; Joseph Tremoulet Cc: Bataev, Alexey; Reid Kleckner (reid at kleckner.net); LLVM Developers Mailing List Subject: RE: [LLVMdev] RFC: Native Windows C++ exception handling It’s an interesting problem though. If an instruction is in the landing pad block but not inside a begincatch/endcatch pair it will be interpret...

..., I am wary of relying on this line for >> anything. >> >> If you want to know who reviewed a change, better click on the >> Differential Revision link and go to the source of truth. >> >> -- >> Mehdi >> >> On Thu, Jan 2, 2020 at 10:44 AM Joseph Tremoulet via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> +1 to keeping “Reviewed by”. Whenever I’m fixing a bug in unfamiliar >>> code, I look at both author and “reviewed by” from the history of that code >>> to help pick reviewers for my change. &g...

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