search for: ramosian

On Tue, Oct 25, 2011 at 5:06 AM, Bill Wendling <wendling at apple.com> wrote: > Good day! > > To get ready for the release, we need to make sure that the list of external open source projects using LLVM 3.0 (file:///Volumes/Sandbox/llvm/llvm.src/docs/ReleaseNotes.html#externalproj) is up to date. Please send me an email with the project's name and a short description of it.

On Fri, Jan 13, 2012 at 10:31 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Also, this can be easily reproduced with the following command: > > valgrind --tool=memcheck --show-reachable=yes --leak-check=full > --track-origins=yes --leak-check=full opt -disable-opt -O0 <some random > bitcode file> > > > > Micah > Hi Micah, the

On Wed, Oct 26, 2011 at 12:33 PM, Alexander Potapenko <ramosian.glider at gmail.com> wrote: > On Tue, Oct 25, 2011 at 5:06 AM, Bill Wendling <wendling at apple.com> wrote: >> Good day! >> >> To get ready for the release, we need to make sure that the list of external open source projects using LLVM 3.0 (file:///Volumes/Sandbox/llvm...

...har *argv[]) { if (argc != 2) { fprintf(stderr, "%s num-calls\n", argv[0]); exit(EXIT_FAILURE); } myfunc(atoi(argv[1])); exit(EXIT_SUCCESS); } On Tue, Apr 5, 2011 at 4:49 PM, Alexander Potapenko <ramosian.glider at gmail.com> wrote: > Hi James, > > We've indeed passed the appropriate (and even excessive) flags to the > appropriate pipeline parts, that is: > >  llvm-gcc -O1 -fno-omit-frame-pointers -g $in -emit-llvm -S -o $name.ll >  llc --disable-fp-elim $name.ll -o $name...

Hi James, We've indeed passed the appropriate (and even excessive) flags to the appropriate pipeline parts, that is: llvm-gcc -O1 -fno-omit-frame-pointers -g $in -emit-llvm -S -o $name.ll llc --disable-fp-elim $name.ll -o $name.S g++ -fno-omit-frame-pointers -c $name.S , but that didn't work Alex On Tue, Apr 5, 2011 at 4:40 PM, James Molloy <James.Molloy at arm.com> wrote:

Good day! To get ready for the release, we need to make sure that the list of external open source projects using LLVM 3.0 (file:///Volumes/Sandbox/llvm/llvm.src/docs/ReleaseNotes.html#externalproj) is up to date. Please send me an email with the project's name and a short description of it. Alternatively, if the project was commented out and you would still like to be listed, just tell me

> Another thing that might work would be to insert inline assembly > statements that define symbols before and after the loop.  The LLVM > optimizations shouldn't move loop code around these inline assembly > statements (if the statements are labeled as modifying memory in a > volatile manner), but optimizations between the inline assembly > statements should remain

> > Alex, > Now, the patch is actually a bit confusing to me. > EP_AlwaysEnabled should mean "works with O0 after inliner and with >= O1 > somewhere late", but it doesn't look like it works this way (otherwise, you > wouldn't need to call PMBuilder.addExtension twice). > ? This was actually my question to Devang. Any other suggestions for the EP name?

Hi LLVM devs, consider I've got an instrumentation pass that adds some code (say, function calls) before some memory access instructions and marks those calls with some special metadata. I want the compiler to lower the instrumentation code to a sequence of no-ops while generating the object code. For example, the assembly for the following code: 1 void _instr(); // the instrumentation

On Thu, Feb 2, 2012 at 12:25 PM, Umesh Kalappa <umesh.kalappa0 at gmail.com> wrote: > Hi There , > > Again ,I'm newbie to LLVM  and please pardon me ..if you guys  feel that > ,the below question is very basic :) > > Here i go ,compiled the below sample with clang i.e clang enum.c -S > -emit-llvm and there respective file are > > $ cat enum.c > int main()

Hi all, we're working on compile-time instrumentation for ThreadSanitizer (a data race detector, see http://code.google.com/p/data-race-test and http://code.google.com/p/data-race-test/wiki/CompileTimeInstrumentation), which is implemented as an opt plugin that is ran for each client C/C++ module we compile. To build a binary consisting of several modules the following steps are performed:

Hi everyone, We're doing some compile-time instrumentation according to the following scheme: llvm-gcc -O1 -g $in -emit-llvm -S -o $name.ll opt -O2 -load Instr.so $INSTR_FLAGS $name.ll -S -o $name-inst.ll llc $name-inst.ll -o $name.S g++ -c $name.S However it turns out that the code instrumented this way is missing frame pointers (e.g. backtrace() and/or libunwind cannot unwind