similar to: [LLVMdev] Absolute assembler output

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

Quoting Richard Pennington <rich at pennware.com>: > 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 Hi your question is reasonable, but it is probably out of scope for LLVM.

Hi, Nikolaos Kavvadias wrote: > Quoting Richard Pennington <rich at pennware.com>: > > 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? > > your question is reasonable,

Hi, I just updated from r190763 to r191137 and started getting failures in generated assembly language when debug info is enabled. Here is the test case: // Compile and run for every target. // RUN: %ecc -g -o %t %s && %t // FAIL: %armecc -g -o %t %s && %armrun %t // FAIL: %armebecc -g -o %t %s && %armebrun %t // RUN: %i386ecc -g -o %t %s && %i386run %t // FAIL:

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

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

Interesting. File please? Thanks. On Sep 21, 2013 6:01 AM, "Richard Pennington" <rich at pennware.com> wrote: > Hi, > > I just updated from r190763 to r191137 and started getting failures in > generated assembly language when debug info is enabled. Here is the test > case: > > // Compile and run for every target. > // RUN: %ecc -g -o %t %s && %t

If it thinks the symbol is in the BSS section, then it should never have tried to use .comm to emit it I think. On x86 it does not try to mix and match, which is why it works. AFAIK comm symbols are regarded as having no section, rather than being bss, so I think it's a bug in whatever code printed that .comm statement. I'll look into this tomorrow. > Eric Christopher

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

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

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 =

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

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

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

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

(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

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