similar to: [LLVMdev] Debug info

Devang Patel wrote: > Hi Richard, > > How do you produce this LLVM assembly? In newest form, > llvm.dbg.func_start intrinsic is not used. > - > Devang > Hi Devang, The assembly is disassembled from bitcode that I create. I must be using obsolete remnants of the API. I'm calling EmitFunctionStart(), EmitStopPoint(), etc. What should I be using? -Rich

Hi Richard, How do you produce this LLVM assembly? In newest form, llvm.dbg.func_start intrinsic is not used. - Devang On Tue, Nov 3, 2009 at 5:48 AM, Richard Pennington <rich at pennware.com> wrote: > Hi, > > I'm trying to use the new debug info and I seem to have broken something. > The attached LLVM assembly is the result of compiling a simple main() > function. If I

On Sun, Aug 16, 2009 at 11:47 AM, Richard Pennington<rich at pennware.com> wrote: > Richard Pennington wrote: >> >> Hi, >> >> The enclosed patch preserves debug information about compilation units, >> functions, and line number information when doing bitcode linking. I'm not >> easily able to try this for non-bitcode linking. Could someone familiar

Hi, The enclosed patch preserves debug information about compilation units, functions, and line number information when doing bitcode linking. I'm not easily able to try this for non-bitcode linking. Could someone familiar with debug info take a look and tell me if it appears to be benign? The rational is that formerly the compile units and subprogram definitions were made into a single

Richard Pennington wrote: > Hi, > > The enclosed patch preserves debug information about compilation units, > functions, and line number information when doing bitcode linking. I'm > not easily able to try this for non-bitcode linking. Could someone > familiar with debug info take a look and tell me if it appears to be > benign? > > The rational is that

Hi, I have a little conundrum. I want to bitcode link a whole program, but I've run into a roadblock. During code generation on a processor that doesn't support e.g. floating point, a floating point mul is turned into a function call. This isn't known at bitcode linking time so the appropriate bitcode for the mul isn't linked. Is there a pass I can run that will do the

Eli Friedman wrote: > 2009/8/2 Richard Pennington <rich at pennware.com>: >> The following fails on x86_64 because of the output constraint '0'. >> My question is, is this legal. LLVM complains about the size difference >> (32 vs 64), but it is the same register (ax). >> Works on x86. >> >> %42 = call i64 asm sideeffect

2009/8/2 Richard Pennington <rich at pennware.com>: > Eli Friedman wrote: >> 2009/8/2 Richard Pennington <rich at pennware.com>: >>> The following fails on x86_64 because of the output constraint '0'. >>> My question is, is this legal. LLVM complains about the size difference >>> (32 vs 64), but it is the same register (ax). >>>

----- Original Message ----- > From: "Hal Finkel via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Richard Pennington" <rich at pennware.com> > Cc: llvm-dev at lists.llvm.org > Sent: Wednesday, September 7, 2016 7:37:50 AM > Subject: Re: [llvm-dev] [PowerPC] Recent branch too far breakage > > Hi Rich, > > It is hard to tell, but there

Hi, I know my last question was very vague (i.e. "It stopped working, what went wrong?"), so here is a little more concrete example: If I run the optimizer (opt) on this code snippet with -std-compile-opts the optimizer hangs. ; ModuleID = 'test.ubc' target datalayout =

I've just started looking into code generation and have a newbie question: Is there enough information in the .td files to make a tool to automatically generate an assembler from them? Is a project like that in the works? -Rich

Anyone mind if I add "x86" to Triple.cpp to match x86? I'd like to use the name x86 for consistency. -Rich

The following fails on x86_64 because of the output constraint '0'. My question is, is this legal. LLVM complains about the size difference (32 vs 64), but it is the same register (ax). Works on x86. %42 = call i64 asm sideeffect "syscall\0A\09", "={ax},0,{di},~{dirflag},~{fpsr},~{flags}"(i64 231, i64 %41) nounwind ; <i64> [#uses=2] -Rich

On Sat, May 17, 2008 at 11:34 AM, Richard Pennington <rich at pennware.com> wrote: > If I run the optimizer (opt) on this code snippet with -std-compile-opts > the optimizer hangs. > > > ; ModuleID = 'test.ubc' > target datalayout = >

This fixes a segmentation fault in the system call's error handling path with dynamically-linked binaries on PowerPC64 little endian. The system call stub wasn't loading up r2 with the appropriate TOC value in its global entry point. The r2 setup code comes from the FUNC_START macro in gcc [1] and an equivalent one can also be found in the LOCALENTRY macro in glibc [2]. On the ELFv2 ABI

Hi cschen, Here are the test scripts which I written when I was developing ARM exception handling support: https://github.com/loganchien/libcxx-scripts The script should work on Debian wheezy (cross-compiling from amd64 to armhf.) In general, here are the necessary steps: 1. Get a working arm-linux-gnueabihf gcc/g++ toolchain (for the headers and libraries) 2. Setup the include search path

Hi All, I have installed LinkTimeOptimization.html document in doc directory to describe LTO interface. - Devang

I updated DwarfDebug to use section offset, instead of hard coding 0, to handle LTO properly. r107202. Thanks for brining this up. - Devang On Tue, Jun 29, 2010 at 11:27 AM, Devang Patel <devang.patel at gmail.com> wrote: > DW_AT_stmt_list attribute's value is a section offset to the line no > info for current compilation unit. If there is only one  compilation > unit

Hi Devang, GlobalModRefPass is also a ModulePass and it uses CallGraph Analysis. So, I think it should not necessary to extend CallGraphSCCPass to use CallGraph information. Module Pass shoule be sufficient... --Kapil On 10/8/08, Devang Patel <dpatel at apple.com> wrote: > Hi Kapil, > > On Oct 8, 2008, at 10:19 AM, kapil anand wrote: > >> Hi all, >> >> I

Devang, Wonderful! Thanks for explaining this, it really helps. I took the liberty of fixing a few grammatical errors and some HTML usage/style things. No significant change to the content was made. Reid. On Mon, 2006-08-14 at 11:23 -0700, Devang Patel wrote: > Hi All, > > I have installed LinkTimeOptimization.html document in doc directory > to describe LTO interface. >