similar to: [LLVMdev] Transition C->bitcode->assembly->object looses frame pointers

Hi, The -disable-fp-elim flag must be passed to the part of the compilation process that actually performs that optimisation pass - when you run clang/llvm-gcc in one invocation, obviously it will just be that invocation, but in your first case it would be the llc command. That is where the IR gets lowered, so is where the FP elimination takes place. Pass flags are not, as far as I'm aware,

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:

Below is an example of using backtrace() obtained from man backtrace and the test results: $ gcc bt.c -o bt-gcc $ ./bt-gcc 4 backtrace() returned 4 addresses ./bt-gcc() [0x4007e3] ./bt-gcc() [0x400874] ./bt-gcc() [0x40089b] ./bt-gcc() [0x400894] $ llvm-gcc bt.c -o bt-llvm-gcc $ ./bt-llvm-gcc 4 backtrace() returned 4 addresses ./bt-llvm-gcc() [0x40074b] ./bt-llvm-gcc() [0x400809]

Hi Alexander, while I can reproduce the problem with your example, inspection of the assembler shows that the frame pointer is being correctly set up in each function. So I don't think the problem is due to frame pointer elimination. Ciao, Duncan.

Hi Alexander, I took a look at how backtrace works and it doesn't use the frame pointer at all, instead it uses dwarf unwind tables. So to make it work using llc you need to do as follows: $ llc -unwind-tables bt.ll -o bt.S $ gcc -o bt-llc bt.S $ ./bt-llc 4 backtrace() returned 4 addresses ./bt-llc() [0x4007aa] ./bt-llc() [0x400856] ./bt-llc() [0x40087c] ./bt-llc() [0x400875] Ciao, Duncan.

Dear lazydev, I'm writing an instrumentation pass that depends on AliasAnalysis. My getAnalysisUsage() looks as follows: 2453 void ThreadSanitizer::getAnalysisUsage(AnalysisUsage &AU) const { 2454 AU.addRequired<TargetData>(); 2455 AU.addRequired<AliasAnalysis>(); 2456 } and the pass initialization: 2668 char ThreadSanitizer::ID = 0; 2669

On Nov 29, 2011, at 11:26 PM, Alexander Potapenko wrote: >> >> 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). >>

> On 2015-May-15, at 13:15, Teresa Johnson <tejohnson at google.com> wrote: > > What isn't clear to me is what all uses the available > externally linkage type currently - do you happen to know? It's used for the `inline` keyword in the C language. If you do a `git grep available_externally -- test/` inside a clang checkout you might find some other uses. $ cat

Hi Alexander, I had the same error: sincos: /home/marcusmae/rpmbuild/BUILD/llvm/lib/VMCore/PassManager.cpp:635: void llvm::PMTopLevelManager::schedulePass(llvm::Pass*): Assertion `PI && "Expected required passes to be initialized"' failed. The solution was to add: PassRegistry &Registry = *PassRegistry::getPassRegistry(); initializeCore(Registry);

On Tue, Nov 29, 2011 at 4:31 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Tue, Nov 29, 2011 at 8:56 AM, Alexander Potapenko <glider at google.com>wrote: > >> PS. Should we move the discussion to cfe-commits or it's ok to >> continue the review process here? >> > > For future reference, please send patches which touch both LLVM and Clang

Hi, It looks like the default for -fomit-frame-pointer has recently changed from "no" to "yes at O1 and higher", but I did not see the commit. Was that intentional? (AddressSanitizer uses frame pointers to unwind stack, that's how we noticed). Thanks, --kcc -------------- next part -------------- An HTML attachment was scrubbed... URL:

> >> + EP_EnabledOnOptLevel0 > > I'd rename this as EP_AlwaysEnabled > Renamed, see the attachment. But note that one needs to add his pass at two extension points: at O0 and wherever else he wanted to add it. Won't such a name confuse the user? E.g. he may think that just adding a pass as "EP_AlwaysEnabled" should be enough to have it at any optimization

+cfe-commits (as the patch touches both llvm and clang) On Wed, Nov 30, 2011 at 9:33 AM, Devang Patel <dpatel at apple.com> wrote: > > On Nov 29, 2011, at 11:26 PM, Alexander Potapenko wrote: > > >> > >> Alex, > >> Now, the patch is actually a bit confusing to me. > >> EP_AlwaysEnabled should mean "works with O0 after inliner and with >=

On Wed, Nov 30, 2011 at 11:04 AM, Kostya Serebryany <kcc at google.com> wrote: > +cfe-commits (as the patch touches both llvm and clang) > > On Wed, Nov 30, 2011 at 9:33 AM, Devang Patel <dpatel at apple.com> wrote: > >> >> On Nov 29, 2011, at 11:26 PM, Alexander Potapenko wrote: >> >> >> >> >> Alex, >> >> Now, the

On Tue, Dec 27, 2011 at 11:48 AM, Kostya Serebryany <kcc at google.com> wrote: > Hi, > > It looks like the default for -fomit-frame-pointer has recently changed from > "no" to "yes at O1 and higher", but I did not see the commit. > Was that intentional? Yes; r146586. -Eli

On Tue, Nov 29, 2011 at 8:56 AM, Alexander Potapenko <glider at google.com>wrote: > PS. Should we move the discussion to cfe-commits or it's ok to > continue the review process here? > For future reference, please send patches which touch both LLVM and Clang to llvm-commits and cfe-commits. However, looking at the Clang side of the patch, it is totally fine. =D --------------

> > 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 Not sure if this is a clang or llvm related question so I'm sending to both mailing lists. Anyways, I have few questions regarding size and execution time of instrumented code: We are trying to run code coverage on memory limited hardware and investigating both (generating gcov output using -coverage and the llvm's own way using -fprofile-instr-generate -fcoverage-mapping clang flags)

On Tue, Dec 27, 2011 at 12:06 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Tue, Dec 27, 2011 at 11:48 AM, Kostya Serebryany <kcc at google.com> > wrote: > > Hi, > > > > It looks like the default for -fomit-frame-pointer has recently changed > from > > "no" to "yes at O1 and higher", but I did not see the commit. > >

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.