similar to: [LLVMdev] Debug information and bitcode linking patch

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

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

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

----- 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

(Fixed the cfe email address) On 12/18/2015 09:34 PM, Tim Northover wrote: > On 18 December 2015 at 19:15, Richard Pennington via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> It turns out that it can with some simple patches. > This sounds really cool. I think we should seriously consider putting > these patches into LLVM mainline. > >> Information on

A while back (2012) there were a few messages related to using YAML config files to set up how clang would build stuff, especially for cross compilers. My ELLCC project is entirely cross compilation focused, so today I decided to play around with the config file idea. Right now it only handles replacing a "-target foo" option with the options defined in the file foo in the

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). >>>

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 = >

I'm using a recent revision of TOT (280704) to build clang/LLVM for PowerPC64 little endian. I'm getting an assembler error when building PPCInstPrinter.cpp: The error is: /tmp/PPCInstPrinter-84c835.s: Assembler messages: /tmp/PPCInstPrinter-84c835.s:7671: Error: operand out of range (0x0000000000008004 is not between 0xffffffffffff8000 and 0x0000000000007ffc) The offending line is

Chris Lattner wrote: > On Dec 22, 2007, at 2:40 AM, Richard Pennington wrote: > >> Does Elsa provide an advantage over g++? For me, understanding it is a >> big plus. ;-) In addition, Elsa has a Berkeley-like license which I >> prefer. > > Ok. If you're not planning on extending the front-end, > understandability doesn't really matter ;-). I get

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

Hi, I have completed enough of the Nios2 code generator that I think it is appropriate to bring it into the source tree. What is the best approach to take? It all sits in one directory, of course: lib/Targets/Nios2. Besides that directory, the only other change I've made is to configure. The code generator is complete, but requires more testing. How should I proceed? Should I commit

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

Saw this mentioned on Lambda, and thought it was worth pointing out (though I'm betting most of you are Lambda readers). Looks like it's a new approach to mapping out optimizations and picking the best ordering/grouping. http://www.cse.ucsd.edu/~rtate/publications/eqsat/ Just watched the video and am settling down to read the paper, and it looks interesting so far. Anyone more

I'm a little further along now. I've started to put together a simple driver for Elsa and LLVM that I'm calling "ellsif" (cute name, I think it works). The file being compiled is a "printf" function. Here are timing results for optimized and unoptimized runs: [~/elsa/ellsif] dev% ./ellsif -v test/ofmt.i -time-actions Adding test/ofmt.i as a preprocessed C file

I'm trying to implement *MUL_LOHI for my processor. My processor has mulxss (e.g.) that gives the 32 high bits of a 64 bit multiply. I tried this in ios2ISelDAGToDAG.cpp: /// Mul/Div with two results case ISD::SMUL_LOHI: case ISD::UMUL_LOHI: { SDValue Op1 = Node->getOperand(0); SDValue Op2 = Node->getOperand(1); AddToISelQueue(Op1);