similar to: [LLVMdev] An "x86" target?

On Tue, Jul 28, 2009 at 5:35 AM, Richard Pennington<rich at pennware.com> wrote: > Anyone mind if I add "x86" to Triple.cpp to match x86? I would really rather you didn't. :) Triple is intended to match the "target triples", for example the autconf/config.guess type stuff. I really don't want to add to the genetic diversity of that namespace. - Daniel

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

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 =

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

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

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

Hi, Did this make it into review / commit? It's probably too late for 3.6 if it didn't, but I'd love to see it in 3.7. It would also be nice if this support could be something a bit more general in LLVM, rather than specifically in clang, so that other llvm tools (e.g. llvm-objdump) could take advantage of a similar format for target description files if they need something more

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

Well, at least it works on some programs across all arches. That was some great testing you've done for us. :-) Thanks! Renato On 28 Oct 2016 23:51, "Richard Pennington" <rich at pennware.com> wrote: > On 10/28/2016 05:27 PM, Renato Golin wrote: > >> On 28 October 2016 at 23:02, Rui Ueyama via llvm-dev >> <llvm-dev at lists.llvm.org> 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 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

I'm porting the musl C library to ARM Thumb. It looks like inline asm is failing in some cases. Here's one: The lseek system call looks like this: ... off_t result; return syscall(SYS__llseek, fd, offset>>32, offset, &result, whence) ? -1 : result; ... Which eventually goes through this macro: static inline long __syscall5(long n, long a, long b, long c,

On 26 November 2013 16:44, Renato Golin <renato.golin at linaro.org> wrote: > On 26 November 2013 15:36, Rob Stewart <robstewart57 at gmail.com> wrote: >> >> $ clang -v -target armv7a-linux-eabi -mcpu=cortex-a9 -mfloat-abi=soft >> -mfpu=neon helloworld.c > > Hi Rod, I'm honoured. (But Rob is also OK) :-) > You need cross-binutils installed on your

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

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 Richard, > You changes work for me also. I applied something similar to the Mips CG > and they worked there also. Thanks again. I can't reproduce the same problem here for Mips using clang, could you please attach the bitcode you used? Thanks -- Bruno Cardoso Lopes http://www.brunocardoso.cc