search for: keno

Keno, Perhaps you can view the problem to be the memcpys themselves, We humans can look at the memcpys and see loads and stores but to almost all optimizer passes they aren’t what it is looking for, They instead see function calls which they mostly don’t touch, If these memcpys were inlined i...

Keno, Hmmm, seems like you are saying “copy-in-copy-out” argument semantics are required by the language, Otherwise you would be using “by-reference" argument semantics, And that CICO is easiest for you to represent with memcpy. Usually there are some very subtle issues with CICO and the...

...lly I believe we were using the multiplication by -1.0 because it was a more reliable negation that 0-x (from 3.0 until 3.3 at least). Is there a good reason why multiplication by NaN should kill the sign bit? On Thu, Aug 7, 2014 at 1:22 AM, Owen Anderson <resistor at mac.com> wrote: > Hi Keno, > > From IEEE 754-2008, §5.5.1: > Implementations shall provide the following homogeneous quiet-computational sign bit operations for all > supported arithmetic formats; they only affect the sign bit. The operations treat floating-point numbers and > NaNs ali...

Hi Dale, I don't think that Keno's rewrite is applicable for a bug fix release. We have, in the last year, moved to having some dot releases for our older releases, but these are definitely bug fix only and low risk as we don't want to break anything new. The release documentation is located here: http://llvm.org/docs/Ho...

...a new thread, let me ask you the next question. One of the shared libraries I load calls strtol and msan fails to intercept it. Why would this be? The library seems to be otherwise implemented. One of the potential culprits I saw is that strtol is marked as strong in libc. Is there any workaround? Keno On Thu, Apr 9, 2015 at 3:00 PM, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: > On Thu, Apr 9, 2015 at 9:24 PM, Keno Fischer > <kfischer at college.harvard.edu> wrote: > > Hi everyone, > > > > I ran into a false positive with memory sanitizer due to it...

...Generally speaking, correct implementations of fabs, fneg, and copysign are built out of logical operations rather than arithmetic ones. > > I don’t know offhand why the behavior of multiplication of multiplication in APFloat was changed. > > —Owen > > On Aug 6, 2014, at 10:45 PM, Keno Fischer <kfischer at college.harvard.edu> wrote: > >> Ok, I had forgotten about sNaNs. Doesn't the same caveat apply to >> 0-sNaN then though or does that not signal? Does that mean we need a >> separate way to handle negate in the IR? Funnily enough, historically &gt...

Hi Keno, The part that scares me a bit is > and then adjust the other methods to not > bail out two quickly when encountering a weak symbol. I would very much appreciate if you could implement this; I don't have enough knowledge of the MCJIT nor llvm CodeGen internals... I will happily try it...

...reference, here's what I'm using on unix as a workaround as long as this is not fixed: llvm-config --libfiles | xargs -n 1 -I {} sh -c 'test -f {} && echo {}' On Tue, May 15, 2012 at 1:07 AM, Albert Graef <Dr.Graef at t-online.de> wrote: > On 05/13/2012 02:46 AM, Keno Fischer wrote: > > Currently, there's a regression in llvm-config in both the 3.1 Release > > branch and trunk (http://llvm.org/bugs/show_bug.cgi?id=11886). The > > attached patch fixes that. It would be great if this could be reviewed > > and still integrated into 3.1....

Yes, it would be great to get that fixed. On Wed, Feb 5, 2014 at 4:09 PM, Evgeniy Stepanov <eugeni.stepanov at gmail.com>wrote: > On Thu, Feb 6, 2014 at 12:21 AM, Keno Fischer > <kfischer at college.harvard.edu> wrote: > > Looks like when you materialize the stores, you should check the size of > the > > the store and emit an appropriate amount of stores to the origin shadow > (or > > just a memset intrinsic?). > > Yes. Ther...

On Fri, May 22, 2015 at 4:14 PM, Keno Fischer <kfischer at college.harvard.edu> wrote: > This might be related to GOT relocations. I rewrote that part of > RuntimeDyldELFbecause I was seeing this issue. Have you tried trunk? > I didn't notice that you were running 3.5 the first time I read this. Keno's diagnos...

Currently, there's a regression in llvm-config in both the 3.1 Release branch and trunk (http://llvm.org/bugs/show_bug.cgi?id=11886). The attached patch fixes that. It would be great if this could be reviewed and still integrated into 3.1. Thanks, Keno -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120512/e91ddc99/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 11886.diff Type: application/octet-strea...

....org/viewvc/llvm-project?view=rev&revision=156837 http://llvm.org/viewvc/llvm-project?view=rev&revision=156838 Let me know if your experience disagrees. I'll try and get these into 3.1 if Bill lets me after the buildbots give a check mark. - Daniel On Tue, May 15, 2012 at 5:38 AM, Keno Fischer <kenof at stanford.edu> wrote: > Ok, I attached it to the bug. For reference, here's what I'm using on unix > as a workaround as long as this is not fixed: > llvm-config --libfiles | xargs -n 1 -I {} sh -c 'test -f {} && echo {}' > > > On Tue,...

Looks like when you materialize the stores, you should check the size of the the store and emit an appropriate amount of stores to the origin shadow (or just a memset intrinsic?). On Wed, Feb 5, 2014 at 2:13 PM, Keno Fischer <kfischer at college.harvard.edu>wrote: > The @entry stuff is just a gdb artifact. I've been tracking this back a > little further, and it seems there's at least an origin propagation problem: > > (gdb) list > 281 goto value_to_pointer_error; > 2...

...here was no compliant way to implement it in LLVM. Does somebody remember what the arguments for the behavior change in r187314 were? It seems more sane to me to preserve the sign bit than to unconditionally overwrite it, especially considering that the hardware doesn't do it this way. Thanks, Keno

Hi Keno, Could you give a short high-level overview of the way Julia works now with MCJIT instead the JIT: What I gather so far... * Compiled IR functions are emitted to a shadow module. * Any used function is cloned into its own new module and the module is added to MCJIT. * Called functions or globalv...

...the llvm.dbg.cu in this case? > > Sergei > > -----Original Message----- > From: aprantl at apple.com [mailto:aprantl at apple.com] > Sent: Monday, June 19, 2017 5:00 PM > To: Sergei Larin <slarin at codeaurora.org> > Cc: llvm-dev <llvm-dev at lists.llvm.org>; Keno Fischer <keno at juliacomputing.com> > Subject: Re: [llvm-dev] CloneFunctionInto produces invalid debug info > > - old Keno > +current Keno >> On Jun 19, 2017, at 2:59 PM, Adrian Prantl <aprantl at apple.com> wrote: >> >> In your example the instructions...

Hi Keno, I am talking about runtime. The performance of the generated machine code. Not the time it takes to lower the IR to machine code. We typically only JIT once (taking a few secs) and then run the generated machine code for hours. So the JIT time (IR -> machine code) doesn't impact us. C...

- old Keno +current Keno > On Jun 19, 2017, at 2:59 PM, Adrian Prantl <aprantl at apple.com> wrote: > > In your example the instructions in the cloned function have debug locations belonging to a different function, and the function itself is missing a DISubprogram metadata attachment. > &...

...even some logic operations (like select). It could be that b is clean on function entry, but then something uninitialized gets mixed in. Also, what is this @entry stuff? It looks like bitvector_any1 has 6 arguments, but your ccall snippet only sets up tls for 3. On Sun, Feb 2, 2014 at 10:39 PM, Keno Fischer <kfischer at college.harvard.edu> wrote: > I don't think we're doing anything unusual. Here's the relevant snippet from > the generated IR for ccall (after instrumentation): > > ccall: ; preds = %pass6, %113 > %11...

How is ccall() implemented? If it manually sets up a stack frame, then it also needs to store argument shadow values in paramtls. I don't think there is an overflow, unless you have a _lot_ of arguments in a function call. On Sun, Feb 2, 2014 at 9:26 AM, Keno Fischer <kfischer at college.harvard.edu> wrote: > Also, I was looking at the instrumented LLVM code and I noticed that the > LLVM global variable is generated with size 1000, while > kMsanParamTlsSizeInWords == 100, could there be some sort of overflow > happening? > > >...