llvm dev - Sep 2004 - [LLVMdev] Inline Assembly (unique arch string for llvm)

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>

On Thu, 16 Sep 2004, Andrew Lenharth wrote:
> 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.
Hrm, I would much rather just have LLVM be a drop in replacement for a C
compiler.  As such, it should expose identical #defines to GCC.
> 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.
We *will* eventually support inline assembly, it just has not yet been
implemented yet.  Patches accepted :)

-Chris

-- 
http://llvm.org/
http://nondot.org/sabre/

On Thu, 2004-09-16 at 23:45, Chris Lattner wrote:
> On Thu, 16 Sep 2004, Andrew Lenharth wrote:
> > 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.
> 
> Hrm, I would much rather just have LLVM be a drop in replacement for a C
> compiler.  As such, it should expose identical #defines to GCC.
A drop in replacement for "a C compiler" is rather a different
requirement than a drop in replacement for GCC.  If the goal is pure GCC
compatibility then sure, identical defines are fine.  My main point is
software tends to expect certain compilers (or a small number of
compilers) on certain platforms and tends to have work arounds (or
exploits) for their unique "features".  Which do you want to fix? 
Make
config scripts and headers think they are compiling to an arch "llvm"
or
make llvm work for evey assumption a piece of sw makes about how gcc
would behave on that arch/os?  I guess you are thinking the latter.  I
just thought that gcc has enough problems with things breaking when new
versions of gcc come out because they depended too closely on how gcc
behaved on a certain peice of code, that perhaps we don't want to try to
go down that path too.  (for example, although the linux kernel supports
several versions of gcc, there have been a slew of patches recently to
make things work on 3.5).

An argument for a seperate arch string is also that it makes llvm
bytecode (especially with a fully ported c library) very close to being
identical for similar platforms (pointer size and endian size being the
same mostly).  Unless I am missing something here.  Obviously OS
specific interfaces cannot be general, but for most software, those are
wrapped by the c library.

Why don't we have platform independence as an optional bytecode feature
for well behaved programs?  A couple intrinsics to do htonl and friends
would let a peice of bytecode be endian agnostic.

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/20040917/d657fdff/attachment.sig>