similar to: [LLVMdev] Preserving accurate stack traces with optimization?

On 10/30/13 9:56 AM, Quentin Colombet wrote: > Hi Philip, > > Could you define what is an accurate stack trace for your project? > In other words, what do you mean by full and accurate stack frame? > > Without this definition, this is difficult to give you any feedback. > In particular, I do not see what it means when we use inlining. Sure. Just to note, I *think* your

Hi Philip, Could you define what is an accurate stack trace for your project? In other words, what do you mean by full and accurate stack frame? Without this definition, this is difficult to give you any feedback. In particular, I do not see what it means when we use inlining. E.g., what do you expect from code like this: static void fct1(…) { ... } static void fct2(…) { … fct1(…) ... }

Philip, Thanks for the clarification. As far as I can tell, there is currently no way to preserve a full and accurate stack trace while utilizing most of LLVM’s optimization abilities. The work on debug information may help you get the information you need, but I do not think we will provide information on stack frames that have been removed via inlining or tail call. Moreover, if at some point

Actually CCing Eric. On Wed, Oct 30, 2013 at 11:00 AM, Quentin Colombet <qcolombet at apple.com>wrote: > Philip, > > Thanks for the clarification. > > As far as I can tell, there is currently no way to preserve a full and > accurate stack trace while utilizing most of LLVM’s optimization abilities. > > The work on debug information may help you get the information

David, Quentin - Thanks for the feedback. Responses inline. On 10/30/13 11:21 AM, David Blaikie wrote: > Actually CCing Eric. > > > On Wed, Oct 30, 2013 at 11:00 AM, Quentin Colombet > <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: > > Philip, > > Thanks for the clarification. > > As far as I can tell, there is currently

Hi, I have Forecast Class and Observed Class in a data matrix as below. > Sample1 FCT OBS 1 1 5 2 2 4 3 3- 3+ 4 3 3 5 3+ 3- 6 4 2 7 5 1 I want to find the difference between Observed and Forecast Classes. How can I get this done? I tried to following to convert the 1 through 5 classes, to 1 through 7 for both OBS and FCT column. > Sample1$OBS2 <- Sample1$OBS

Hi, Here is a small C++ program: vec.cc: #include <cmath> using v4f32 = float __attribute__((__vector_size__(16))); v4f32 fct1(v4f32 x) { return 1.0 / x; } v4f32 fct2(v4f32 x) { return __builtin_ia32_rcpps(x); } Which is compiled to: vec.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 <_Z4fct1Dv4_f>: 0: c4 e2 79 18 0d 00 00 vbroadcastss

Hi, After reading https://llvm.org/docs/Vectorizers.html#vectorization-of-function-calls I decided to write the following C++ program: #include <cmath> using v4f32 = float __attribute__((__vector_size__(16))); v4f32 fct1(v4f32 x) { v4f32 y; y[0] = std::sin(x[0]); y[1] = std::sin(x[1]); y[2] = std::sin(x[2]); y[3] = std::sin(x[3]); return y; } v4f32 fct2(v4f32 x) { v4f32 y;

Hi Quentin, You are correct, I could manage to get clang to use vrcpps, but not in a satisfying way: clang++ -O3 -march=native -mtune=native \ -Rpass=loop-vectorize -Rpass-missed=loop-vectorize -Rpass-analysis=loop-vectorize \ -ffast-math -ffp-model=fast -ffp-exception-behavior=ignore -ffp-contract=fast \ -c -o vec.o vec.cc 0000000000000140 <_Z4fct4Dv4_f>: 140: c5 f8 53 c8

I have the data similar to the following in a data frame: LastName Department Salary 1 Johnson IT 56000 2 James HR 54223 3 Howe Finance 80000 4 Jones Finance 82000 5 Norwood IT 67000 6 Benson Sales 76000 7 Smith Sales 65778 8 Baker HR 56778 9 Dempsey HR 78999 10 Nolan

On Wed, Oct 30, 2013 at 8:58 PM, Eric Christopher <echristo at gmail.com>wrote: > > On Oct 30, 2013 7:25 PM, "Philip Reames" <listmail at philipreames.com> > wrote: > > > > On 10/30/13 7:09 PM, Philip Reames wrote: > >> > >> David, Quentin - Thanks for the feedback. Responses inline. > >> > >> On 10/30/13 11:21 AM,

On Oct 30, 2013 7:25 PM, "Philip Reames" <listmail at philipreames.com> wrote: > > On 10/30/13 7:09 PM, Philip Reames wrote: >> >> David, Quentin - Thanks for the feedback. Responses inline. >> >> On 10/30/13 11:21 AM, David Blaikie wrote: >>> >>> Actually CCing Eric. >>> >>> >>> On Wed, Oct 30, 2013 at

On 10/30/13 7:09 PM, Philip Reames wrote: > David, Quentin - Thanks for the feedback. Responses inline. > > On 10/30/13 11:21 AM, David Blaikie wrote: >> Actually CCing Eric. >> >> >> On Wed, Oct 30, 2013 at 11:00 AM, Quentin Colombet >> <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: >> >> Philip, >>

>>>>> Hadley Wickham >>>>> on Wed, 8 Aug 2018 09:34:42 -0500 writes: >>>> Method dispatch for `vec_c()` is quite simple because >>>> associativity and commutativity mean that we can >>>> determine the output type only by considering a pair of >>>> inputs at a time. To this end, vctrs provides

El mi?., 8 ago. 2018 a las 19:23, Gabe Becker (<becker.gabe at gene.com>) escribi?: > > Actually, I sent that too quickly, I should have let it stew a bit more. > I've changed my mind about the resolution argument I Was trying to make. > There is more information, technically speaking, in the factor with empty > levels. I'm still not convinced that its the right

Here's another odd question I've been wondering about: Typically a class vtable is an represented as an array of function pointers. Now, since the functions all have different calling signatures, I imagine that you would generate an array of opaque pointers, and then bitcast the pointer to the actual function signature at the call site. However, that's not what I am doing.

On 2009-09-24 22:34, hc2428 at columbia.edu wrote: > Dear developers, > When I try to map line numbers in source code back to LLVM > basicblocks, I meet some problems: there is a source file with 1500 > lines of code, but when I use BasicBlockPass to collect all > DbgStopPoint instructions in this file, I can only get 500 lines of code. > The source code and the collected

As I understand it, LLVM simply gives you support for garbage collectors that you have to implement yourself and link into the final binary, similar to what C's malloc does (it's a library call). The issue with GC's is that they need to be provided info about the stack, thats where LLVM's support comes in. As far as I know, the garbage collector is linked into the final binary

Am 16.12.2011 21:06, schrieb Jon Harrop: > At regular intervals, check if the heap size has exceeded its quota > and, if so, run a GC cycle. I have seen people recommend doing this kind of check whenever hitting a malloc call. I think it nicely scales with the level of heap activity for most programs.

> Mmm. So you want to warn the user that two libraries using different > assertion settings both use the standard library? > > I think warning about actual differences in code, as opposed to differences > in type/vtable layout, is going to be pretty fraught with uninteresting > positives, but if you want to chase that rabbit, it's your time spent. It's probably