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

[Andrew Lenharth]

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>