[LLVMdev] llc -march=ia64 support

Reid Spencer reid at x10sys.com
Wed May 25 03:27:44 PDT 2005


On Wed, 2005-05-25 at 12:08 +0200, Eric van Riet Paap wrote:
> You are right, the machine I am on is a AMD Opteron. I could probably
> generate working code for x86, but I am testing the implications of
> using 64 bits integers. The four weeks is not really important, it's
> just that it would be nice to have really fast code to showcase.

In general, the "C" backend that you're using now is the fastest choice
overall. Although LLVM's x86 backend smokes GCC on several tests, it is
also considerably worse on others. See the nightly test results for
details. So, it depends on what your program does, but you might want to
just stick with the "C" backend to provide reasonable performance until
the x86_64 backend is completed. There was someone working on this a
while back but I forget who. If you want to *really* tune things, you
could write the x86_64 backend to your own specifications ;>

> Something related to this: to test the effect of 64 bits integers I
> replace all reference of int by long in my .ll file.
> The work just fine except for some instruction (like malloc) that demand
> an uint and not an ulong.
> With the shift from the 32 to the 64 bit world, is this something that
> will be enhanced in the future, or would that have to much impact on the
> existing llvm codebase?

I assume you mean the "count" operand of the malloc instruction should
be able to take any size unsigned operand. This probably wouldn't be a
huge hit to the codebase as its limited to a single instruction and it
is a relaxation of requirements rather than a tightening. I think,
however, we'll have to wait for Chris to come back from vacation to
determine whether this is a good idea or not. There are *major* changes
planned to the type system (e.g. move distinction of signedness to the
instructions and not have them in the types) in the 2.0 time frame and
this change could be wrapped into that one. However, the 2.0 time frame
is probably not soon enough (2006 probably) for your project.

> 
> best regards
> Eric

Reid
-------------- 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/20050525/701ede38/attachment.sig>


More information about the llvm-dev mailing list