[LLVMdev] Inline Assembly (unique arch string for llvm)

[Andrew Lenharth]

On Mon, 2004-09-13 at 11:40, John Criswell wrote:
> My impression is that inline assembly bites us a lot not because it's 
> used a lot but because the LLVM compiler enables #defines for the i386 
> platform that we don't support.
> 
> I think a lot of code has the following:
> 
> #ifdef _i386
> inline asm
> #else
> slow C code
> #endif
> 
> The LLVM GCC compiler still defines _i386 (or its equivalent), so 
> configure and llvm-gcc end up trying to compile inline assembly code 
> when they don't really need to.
> 
> I have to admit that this is an impression and not something I know for 
> sure, but it seems reasonable that many application programs use i386 
> assembly because i386 is the most common platform, and speedups on it 
> are good.
> 
> Changing llvm-gcc to disable the _i386-like macros might make 
> compilation of userspace programs easier.

When I was working on porting glibc (currently being held up by a C99
support bug) the most straight forward approach was to define a new
architecture string and implement a new target in glibc based on that
machine string.

So I propose that llvm-gcc not consider itself any type of x86-linux (or
what ever it platform it was compiled on), but rather create a new
architecture, say llvm (or perhaps 2, one for each bit and little
endian).  Thuse llvm-gcc -dumpmachine would return llvm-os.

This would make system library (and OS kernel!) ports easier to maintain
since arch llvm would be supported by adding stuff rather than changing
stuff, and all the inline asm for known archs would go away and the C
version would be used.  In most cases the config scripts should consider
compiling with llvm on a host as a cross compile from host arch to arch
llvm.

Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040916/017f74ff/attachment.sig>