similar to: -mllvm -track-memory precision

Hi, I have been trying to use the -mllvm -debug option for clang but without much success. Do I need to build in any specific manner for this to work ? On using -mllvm -debug as follows I get the error below. $>clang -ccc-host-triple armv7-none-linux-gnueabi -mfloat-abi=softfp -mfpu=neon -mcpu=cortex-a9 -mllvm -debug fdct.i -S clang (LLVM option parsing): Unknown command line argument

Thanks for the reply. On 28 April 2014 20:01, Reid Kleckner <rnk at google.com> wrote: > The problem with tcmalloc seems like a real problem. I can't think of any > good workarounds. My best worst idea is to try to figure out if malloc is > coming from libc with dlsym and dlopen, and then use that to decide whether > we add these two numbers together. I'm not sure we

Hi, > > I guess this is because the test suite is trying to run "llvm-gcc > > -mllvm -disable-llvm-optzns", which never seems to work, because > > llvm-gcc mangles the command line before it gets to cc1plus. > That's correct. The driver changes the order of the options provided. > You need to provided this option to cc1 / cc1plus directly Dan fixed this

Hello, Jay > I guess this is because the test suite is trying to run "llvm-gcc > -mllvm -disable-llvm-optzns", which never seems to work, because > llvm-gcc mangles the command line before it gets to cc1plus. That's correct. The driver changes the order of the options provided. You need to provided this option to cc1 / cc1plus directly > Is it just me having this

On 20 July 2011 20:24, Bhandarkar, Pranav <pranavb at quicinc.com> wrote: > I have been trying to use the -mllvm -debug option for clang but without much success. Do I need to build in any specific manner for this to work ? You need to build LLVM with assertions enabled.

While checking on the status of https://llvm.org/bugs/show_bug.cgi?id=22657 in current llvm/clang trunk, I noticed that the previous work-around for recovering the missing in-lining of the c-ray 1.1 benchmarks of passing -mllvm -inline-threshold=500 no longer works. This regression doesn't exist in the 3.8.0 release. Any idea what commit in 3.9svn might have introduced this regression?

Hi, This is a proposed fix for bug 16847 [1]. It is essentially the patch provided by Martin Nowack in the bug report but I have added a test case and an ifdef macro around the modified code in Process::GetMallocUsage() The issue seems to be that the ptmalloc2 allocator used in glibc (in my case 2.19) does not include mmap()'ed memory in mallinfo.uordblks and so mallinfo.hblkhd needs to be

Hi, > I'm trying to run some of the test suite using the instructions here: > > http://llvm.org/docs/TestingGuide.html#quicktestsuite > > I've built llvm myself, but I'm using pre-built binaries of llvm-gcc > (from http://llvm.org/prereleases/2.5/llvm-gcc4.2-2.5-x86-linux-RHEL4.tar.gz). > > Here's what happens: the llvm testsuite (from svn, right?) uses

I have prices that I am finding difficult to compare with ==, > and >, due to precision. For example: the numbers should match, with '==', but they differ in the magnitude of 1e-14 due to bunch of calculations that I run on them. Programming with java, I am used to implementing a function that compares the difference between the numbers to a pre determined precision factor. This

I'm trying to run some of the test suite using the instructions here: http://llvm.org/docs/TestingGuide.html#quicktestsuite I've built llvm myself, but I'm using pre-built binaries of llvm-gcc (from http://llvm.org/prereleases/2.5/llvm-gcc4.2-2.5-x86-linux-RHEL4.tar.gz). Here's what happens: foad at debian:~/svn/llvm-project/test-suite/trunk$ ./configure

Hi, The code in Support/Timer.cpp has strangely inconsistent behavior for printAll vs printJSONValues. The former can work multiple times, while the latter calls prepareToPrintList(), which stops all timers, hence making all further attempts to print timers crash. Would it be possible not to call prepareToPrintList on printJSONValues, or at least make it optional? I am trying to serialize

Unless mem2reg does something other than my understanding of it, I can't see why any pass would "require" that... It is not guaranteed to do anything to any particular piece of code, so relying on it seems very unreliable, I would think. -- Mats On 22 March 2016 at 04:32, Kevin Hu via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hi, > > > Is there any way that

On 10/07/2011 03:43 PM, Marcello Maggioni wrote: > 2011/10/7 Marcello Maggioni<hayarms at gmail.com>: >> Hi, >> >> for example this loop: >> >> #include<stdio.h> >> >> int main() >> { >> int A[1024]; >> int j, k=10; >> for (j = 1; j< 1024; j++) >> A[j] =

----- Original Message ----- > From: "Gerolf Hoflehner" <ghoflehner at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Dev" <llvmdev at cs.uiuc.edu>, "Jiangning Liu" <liujiangning1 at gmail.com>, "George Burgess IV" > <george.burgess.iv at gmail.com> > Sent: Monday, September 15, 2014

I was trying the new feature you introduce about printing out the graphs, so I updated my version of llvm/clang/polly synchronizing them to the last version, but I get this error launching clang (also , I recently switched to MacOS X for development): $ clang not_so_simple_loop.c -O3 -Xclang -load -Xclang ${PATH_TO_POLLY_LIB}/LLVMPolly.dylib -mllvm -enable-polly-viewer -mllvm -enable-iv-rewrite

Hi folks, Moving the discussion to llvm.dev. None of the changes we talked earlier help. Find attached the C source code that you can use to reproduce the issue. clang --target=aarch64-linux-gnu -c -mcpu=cortex-a57 -Ofast -fno-math-errno test.c -S -o test.s -mllvm -debug-only=licm LICM hoisting to while.body.lr.ph: %21 = load double** %arrayidx8, align 8, !tbaa !5 LICM hoisting to

Dear list, I would like to propose a set of patches which make it possible for a upssched-cmd script to stop a timer at an arbitrary moment. If you find this of interest, I will submit a set of patches to 2.7.4. Roger Introduction ------------ The comments at the top of upssched.c say << * timers can be cancelled at any time before they trigger >>. It would be very useful if

Yes. I've attached an updated patch that does the following: 1. Fixes the partialalias of globals/arguments 2. Enables partialalias for cases where nothing has been unified to a global/argument 3. Fixes that select was unifying the condition to the other pieces (the condition does not need to be processed :P). This was causing unnecessary aliasing. 4. Adds a regression test to

On CINT2006 ARM64/ref input/lto+pgo I practically measure no performance difference for the 7 benchmarks that compile. This includes bzip2 (although different source base than in CINT2000), mcf, hmmer, sjeng, h364ref, astar, xalancbmk On Sep 15, 2014, at 11:59 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Gerolf Hoflehner"

On Thu, Dec 13, 2018 at 11:24:28PM +0000, Steven Luong (sluong) via Virtualization wrote: > Folks, > > > > We came across a memory race condition between VPP vhost driver and the kernel > vhost. VPP is running a tap interface over vhost backend. In this case, VPP is > acting as the vhost driver mode and the kernel vhost is acting as the vhost > device mode. > >