search for: kaylor

...al case. But if we have 'nnan' FMF, then we can fold harder to undef? nnan - Allow optimizations to assume the arguments and result are not NaN. Such optimizations are required to retain defined behavior over NaNs, but the value of the result is undefined. On Wed, Feb 28, 2018 at 3:25 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > What I’m saying is that if we have one operand that is not an undef value > then that operand might be NaN and if it is then the result must be NaN. So > while it may be true that we don’t have a NaN, it is not true that we > definite...

Have got anything started with the dispatchblock plan? From: Reid Kleckner [mailto:rnk at google.com] Sent: Wednesday, May 13, 2015 1:15 PM To: Kaylor, Andrew Cc: David Majnemer <david.majnemer at gmail.com> (david.majnemer at gmail.com); LLVM Developers Mailing List Subject: Re: [WinEH] A hiccup for the Windows C++ exception handling On Wed, May 13, 2015 at 11:03 AM, Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at...

...#39;nnan' FMF, then we can fold harder to undef? > nnan - Allow optimizations to assume the arguments and result are not > NaN. Such optimizations are required to retain defined behavior over > NaNs, but the value of the result is undefined. > > On Wed, Feb 28, 2018 at 3:25 PM, Kaylor, Andrew > <andrew.kaylor at intel.com <mailto:andrew.kaylor at intel.com>> wrote: > > What I’m saying is that if we have one operand that is not an > undef value then that operand might be NaN and if it is then the > result must be NaN. So while it may be tru...

That’s a good question. I’m afraid I don’t know how/if that’s controlled in these tests. From: Johannes Doerfert <johannesdoerfert at gmail.com> Sent: Monday, June 08, 2020 3:05 PM To: Kaylor, Andrew <andrew.kaylor at intel.com>; Lazarev, Vladimir <vladimir.lazarev at intel.com> Cc: LLVM Developers <llvm-dev at lists.llvm.org>; bhomerding at anl.gov; Finkel, Hal J. <hfinkel at anl.gov>; Kruse, Michael <michael.kruse at anl.gov>; Malik,Abid <amalik at bnl...

...that different from just folding the fdiv into undef to begin with? Is it because I can’t choose different values on different code paths? -Andy From: Friedman, Eli [mailto:efriedma at codeaurora.org] Sent: Wednesday, February 28, 2018 3:07 PM To: Sanjay Patel <spatel at rotateright.com>; Kaylor, Andrew <andrew.kaylor at intel.com> Cc: llvm-dev <llvm-dev at lists.llvm.org>; Nuno Lopes <nunoplopes at sapo.pt>; Stephen Canon <scanon at apple.com>; David Majnemer <david.majnemer at gmail.com>; John Regehr <regehr at cs.utah.edu>; Sanjoy Das <sanjoy at pl...

On Wed, Jan 30, 2013 at 8:34 PM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote: > Yes, at some point we definitely should introduce stubs as a last resort > for x86-64 relocations when the sections are too far apart, but I’d like to > avoid it whenever possible.**** > > ** ** > > What I meant in my previou...

...certainty by propagating the undef. The backend can choose whatever encoding of undef makes sense when lowering? And yes, I don't know why FP-div-by-zero would ever be UB. I think that text in the LangRef should be removed regardless of any other outcome here. On Wed, Feb 28, 2018 at 1:18 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > Why is NaN “just ‘undef’ in IR”? NaN is a specific value with well-defined > behavior. I would think that unless the no-NaNs flag is used we need to > preserve the behavior of NaNs. > > > > *From:* Sanjay Patel [mailto:spatel...

It's probably best to open a bug. -Andy From: Alexey Samsonov [mailto:samsonov at google.com] Sent: Thursday, January 31, 2013 12:27 AM To: Kaylor, Andrew Cc: LLVM Developers Mailing List Subject: Re: Assertions in RuntimeDyldELF in ExecutionEngine/MCJIT tests On Wed, Jan 30, 2013 at 8:34 PM, Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>> wrote: Yes, at some point we definitely should introduce st...

...be a way to allocate memory in that range on FreeBSD. The system loader has to do it, right? I just don't know what makes it happen. -Andy -----Original Message----- From: Dr D. Chisnall [mailto:dc552 at hermes.cam.ac.uk] On Behalf Of David Chisnall Sent: Friday, May 10, 2013 11:06 AM To: Kaylor, Andrew Cc: LLVM Developers Mailing List Subject: Re: TLS with MCJIT (an experimental patch) Without the MSP_32BIT part, I consistently hit this assertion: Assertion failed: ((Type == ELF::R_X86_64_32 && (Value <= UINT32_MAX)) || (Type == ELF::R_X86_64_32S && ((int64_t)Value &l...

...e optimized IR and just re-do it every single time for every single time they need an update. It seems like holding on the final output and then visiting all calls, and find/replacing them (:-)) with a new address seems most efficient Thoughts and ideas welcome. On Thu, Mar 26, 2015 at 12:52 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > You don’t need to put all the sections in the same memory block or > maintain the same offsets that had on the host. What I meant was that each > section must be in a contiguous block of memory. > > > > Depending on the mem...

...ned. I just wanted to clarify that the “?” in your comment was indicating that the assertion in the language reference was questionable as opposed to this point being in any way actually uncertain. From: Sanjay Patel [mailto:spatel at rotateright.com] Sent: Wednesday, February 28, 2018 1:05 PM To: Kaylor, Andrew <andrew.kaylor at intel.com> Cc: llvm-dev <llvm-dev at lists.llvm.org>; Nuno Lopes <nunoplopes at sapo.pt>; Stephen Canon <scanon at apple.com>; David Majnemer <david.majnemer at gmail.com>; John Regehr <regehr at cs.utah.edu>; Sanjoy Das <sanjoy at pl...

...t and then allocate +x memory for it all at once, instead of the old model of not knowing how big it was going to be. If we build a module at a time, presumably separate modules don't need to be reachable w.r.t. each other, since they can use PLT-style stubs. On Tue, May 14, 2013 at 8:17 PM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote: > Hi David, > > I believe that assertion indicates that something didn't get loaded into > the lower 2GB of address space. That is, the memory manager isn't > allocating memory in that range. > > I'm sure there must...

The search is linear? If that’s really true, we should fix that. On Oct 21, 2013, at 10:14 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > I should have read this before sending my previous reply. :-) > > I’m not a big fan of default parameters, but some form of what you are suggesting may be useful. See my other comments on this topic in the other reply. > > -An...

...s in the suite I’ve been using to exercise this code. How do you feel about working these changes into trunk to establish a working baseline, even knowing that parts of this are going to be redesigned? -Andy From: Reid Kleckner [mailto:rnk at google.com] Sent: Wednesday, May 13, 2015 2:16 PM To: Kaylor, Andrew; David Majnemer Cc: LLVM Developers Mailing List Subject: Re: [WinEH] A hiccup for the Windows C++ exception handling Basically, I'm trying to come up with a good design doc with David right now so I can mail it out. :) On Wed, May 13, 2015 at 1:43 PM, Kaylor, Andrew <andrew.kaylor...

...that I must treat each section as a block, do you mean that there is inter-block relative offsets need to be maintained? Or that when I get a section, I must copy it to target process memory as a one-shot contiguous block. If it's second, I think we're ok. On Wed, Mar 25, 2015 at 5:39 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > Are you asking about the actual mechanism for transferring the bits into > the remote process or how you locate the generated code in memory? > > > > The mechanism for transferring the bits is outside the scope of MCJIT. > T...

...is to canonicalize to some instruction that yields NaN (and treat that as a NaN constant throughout the pipeline, I guess). Nuno P.S.: With poison you can always fold operations with a poison input to poison (e.g., "fadd %x, poison" => poison). -----Original Message----- From: Kaylor, Andrew Sent: Wednesday, February 28, 2018 11:29 PM Subject: RE: how to simplify FP ops with an undef operand? For the first part of Sanjay’s question, I think the answer is, “Yes, we can fold all of these to NaN in the general case.” For the second part, which the nnan FMF is present, I’m not...

...much better if we grabbed the function names from the module and did the search ourselves so that we could keep some information about the things that didn't match and optimize the next search. -Andy From: Jim Grosbach [mailto:grosbach at apple.com] Sent: Monday, October 21, 2013 4:39 PM To: Kaylor, Andrew; Yaron Keren Cc: <llvmdev at cs.uiuc.edu> Subject: Re: [LLVMdev] An enhancement for MCJIT::getFunctionAddress The search is linear? If that's really true, we should fix that. On Oct 21, 2013, at 10:14 AM, Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at i...

...specially) after the Module is deleted. We should be able to have a local symbol table that’s a DenseMap or something similar to resolve from names to target addresses. That map would be updated as part of the compilation when the object’s symbol table gets read. -Jim On Oct 21, 2013, at 4:55 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > There’s probably a lot that we could do, but I can’t think of anything easy. > > Basically every time we need to look up a symbol by name we’re going to each module and saying “Do you have this symbol?” It would likely be much better...

...level deeper to create a parallel structure to be shared with OpenMP. Vladimir is on vacation right now, but I believe he’ll be preparing a patch for review shortly after he returns. Thanks, Andy From: Johannes Doerfert <johannesdoerfert at gmail.com> Sent: Monday, June 08, 2020 2:00 PM To: Kaylor, Andrew <andrew.kaylor at intel.com> Cc: LLVM Developers <llvm-dev at lists.llvm.org>; bhomerding at anl.gov; Finkel, Hal J. <hfinkel at anl.gov>; Kruse, Michael <michael.kruse at anl.gov>; Malik,Abid <amalik at bnl.gov>; Clement, Valentin <clementv at ornl.gov>;...

Submitted to bugzilla as PR 15729 From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kaylor, Andrew Sent: Thursday, April 11, 2013 1:13 PM To: Weiss, Eran Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Migration from JIT to MCJIT Thanks, Eran. I’m not sure how soon I’ll have a solution for you, but it’s on my to-do list now. I’ll also create a bugzilla record for this problem. -And...