Upstreaming x32 ABI support

Project Infrastructure LLVM Dev List Archives
1

Hi all,

We (Intel) would like to revive this thread on X32 ABI support
upstreaming. X32 ABI homepage is here:

Currently x32 support is available in kernel/glibc/gcc/binutils and
one can install for example Ubuntu 14 with extra x32 lib packages
(apt-get install libc6-dev-x32) to evaluate x32-target code generated
by GCC (gcc supports x32 on Ubuntu 14 out of box).

We are planning to contribute enabling patches in LLVM/Clang trees and
going to provide continuous support for this ABI in the future. Most
of the changes obviously will be submitted to backend.

Our current work is based on:

* what’s currently done in trunk (some changes required for x32 are
already there)
* Michael Liao work done ~2 years ago and available here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120604/058450.html

What’s currently in trunk:

* Triplet x86_64-*-linux-gnux32 (command line support, EnvironmentType
enum to differentiate x32 from x86_64 by getTriple().getEnvironment()
== llvm::Triple::GNUX32)
https://github.com/llvm-mirror/llvm/commit/9dd2a3b1f2c253e20262535bb89b1ab6cc680ece
* ILP32/LP64 differentiation for TargetMachine
https://github.com/llvm-mirror/llvm/commit/a5597f0eaf1f93c6d0bc641a0cc54ecffb33955a
* LEA tuning:
https://github.com/llvm-mirror/llvm/commit/693c37aa86506be657dfaf8835845b0998531c3c
* Bunch of tests (grep for gnux32):
test/CodeGen/X86/imul64-lea.ll
test/CodeGen/X86/stack-update-frame-opcode.ll
test/CodeGen/X86/stack-update-frame-opcode.ll
test/CodeGen/X86/x86-64-sret-return.ll
test/CodeGen/X86/rip-rel-lea.ll
test/CodeGen/X86/x86-64-sret-return-2.ll
test/CodeGen/X86/x86-64-ptr-arg-simple.ll
test/MC/X86/gnux32-dwarf-gen.s

What’s been done by Michael
(http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120604/058450.html)
but not released in trunk:

* Clang Driver support (linker/libraries paths lookup, x32 specific
flags, etc.). This change is rebased, modified and submitted here:
⚙ D4180 [x32] Add X32 support to driver . Welcome to review.
* ELF support for x32. This change is rebased, modified and submitted
here: http://reviews.llvm.org/D4181 . Welcome to review.
* Use EBP/ESP as frame/stack pointer. This patch will be rebased
modified and submitted soon.
* Other cases which require introduction X32 specific instruction
definitions such as JMPX32r/CALLX32r/CALLX32m.
* X32 JIT support
* I hope Michael correct me if I missed anything important

What’s still missing or experiencing issues (just something from the top):

* New tests required and several existing tests fail when extending to x32.
* Pointer and struct return;
* Cast int to pointer;
* Function indirect calls;
* TLS
* Etc.

We don’t plan to introduce new backend from scratch. Major part of the
changes are incremental to X86 backend and extend cases such as

(64bits) ? do-64 : do-32
with
(64bits) ? ((LP64) ? do-64 : do-x32) : do-32

or some shorter form if x32 mimic x86 or x86_64. X32 ABI is very close
to x86-64 ABI.

Our plan is to start from basic stuff, focus on more tests adding and
on stability issues, then continue with performance tuning. So the
first 2 patches I submitted enable “Hello, world!” sample on Ubuntu
14. Patches are here:

                ⚙ D4180 [x32] Add X32 support to driver
                http://reviews.llvm.org/D4181

Next steps are to rebase and split Michael patch, cover with tests and
submit by chunks convenient for review. Then move to other discovered
issues.

Any suggestions and patches review are welcome!

2

It would be great to have a bootstrapping buildbot. I have some spare
hardware, feel free to ping me when Clang can bootstrap on x32.

Dmitri

3

Hi Pavel,

We (the Native Client team) are also interested in helping you get these reviewed and in, especially the x86 backend stuff. Native Client’s x86-64 ABI is similar to x32 so we could probably share a good portion of the code if it’s structured the right way.

-Derek

4

Sure. Will do.
Thanks.

5

Hi Derek,
That's great! I'll add you for all upcoming patches review.

6

Pavel,

Thank you for writing to llvm-dev to describe your work on X32. It sounds like you are committed to making it happen and that other people in the community are also interested in this feature. When you send your patches to llvm-commit for review please CC people who could help with reviewing the patches. One way to find reviewers is to look at the 'svn blame’ line for areas of the code that you are modifying.

Thanks,
Nadav

7

Just a datapoint on why x32 is interesting.

I compiled clang on a ubuntu vm in 32 bits, 64 bits and x32. As a
simple benchmark I then compiled gcc.c from
Large single compilation-unit C programs. The
results were (best of 3 runs, user time)

32:
0m19.529s

64:
0m17.044s

x32:
0m15.768s

8

This is terrific news! :slight_smile: I tried to tackle it on my own before, it
was just too much to take on; or rather, I didn't have the needed
skill or experience to get it working alone.

9

Hi Derek,
What features of x32 would be most relevant from NaCl point of view?
Any common issue or particular optimization?

10

Probably the highest-level changes in code generation (e.g. changes to X86Subtarget, frame lowering, maybe tablegen’ed stuff) is the stuff that’s most likely to overlap and/or conflict.