similar to: [LLVMdev] The mysterious case of the missing GlobalVariables.

If the globals don't have 'external' linkage, the optimizers will happily eliminate them. If they are marked external, attaching the .bc file, reduced if possible, will give people a better chance of helping you. On Sat, Jul 18, 2009 at 8:20 AM, Richard Pennington<rich at pennware.com> wrote: > Hi, > > I've recently been updating my stuff with LLVM TOT with the

Hi, I've restarted my Elsa/LLVM project after three months of having real life intrude. I upgraded my LLVM source to the current trunk. I had to make a few changes to my source, e.g. LLVMFoldingBuilder became IRBuilder and several instances of "new" became "Create". Now, a test case that previously succeeded fails. I run the following script: #!/bin/sh if [ 1 -ne 0 ]

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

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

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

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

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 =

On Wed, Feb 6, 2013 at 5:47 PM, Dmitry Mikushin <dmitry at kernelgen.org>wrote: > > ==== > 2) Second test case: double inclusion of file, that is definitely included > once: > Includes are transitive, so it was being included more than once. With r174582 we now diagnose double inclusions and point you at the previous include location. -- Sean Silva -------------- next part

Hi Sean, Thank you, great catch! Strange, how I missed it with grep... However, this means question 1) becomes more interesting, because it is now clear intrinsics table is included in there, but somehow llvm-lblgen crashes. Best, - D. 2013/2/7 Sean Silva <silvas at purdue.edu> > > On Wed, Feb 6, 2013 at 5:47 PM, Dmitry Mikushin <dmitry at kernelgen.org>wrote: >>

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

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

On Wed, Feb 06, 2013 at 11:47:31PM +0100, Dmitry Mikushin wrote: > Dear all, > > I need your help to understand weird llvm-tblgen behavior. Please take your > favourite version of llvm-tblgen and use it in the root directory of the > archive attached in both bug reports: > > http://llvm.org/bugs/show_bug.cgi?id=15188 > http://llvm.org/bugs/show_bug.cgi?id=15189 $

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

Dear all, I need your help to understand weird llvm-tblgen behavior. Please take your favourite version of llvm-tblgen and use it in the root directory of the archive attached in both bug reports: http://llvm.org/bugs/show_bug.cgi?id=15188 http://llvm.org/bugs/show_bug.cgi?id=15189 ==== 1) First test case: crashing ==== $ ./llvm-tblgen -gen-tgt-intrinsic NVPTX1.td assert(iid <=

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