GCC and LLVM collaboration

Transcription

1 GCC and LLVM collaboration GNU Tools Cauldron 2014, Cambridge, UK Renato Golin LLVM Tech-Lead Linaro 1

2 Agenda What we should discuss: Why & How to collaborate Common projects we already share (the good) Common goals we should have (the bad) Cross-tool standardization process (the ugly) What we should not discuss: License issues Personal grudges Performance Open Source vs. Free Software vs. Libre/Livre/Libero 2

3 Collaboration 3

4 Collaboration Why? There can't shouldn't be only one Protect users from idiosyncrasies Build on each others' work How? Reactively discussing better solutions Pro-actively discussing future implementations Isolate legacy on separate layers / drivers Document and strictly follow documentation 4

5 Collaboration Changes won't happen... Just because we want As quickly as we wish they would As perfectly as we plan them But... Agreeing to a common set of rules Documenting and abiding by them We can, at least... Guide our own internal development process Without breaking other peoples' work 5

6 Common Projects 6

7 Common Projects binutils GAS is required for many targets in LLVM, important for many others (kernel) LD (bfd/gold) is required for all (for now) glibc/newlib/others No LLVM-specific alternative (should it?) sanitizers Same source on both, different integration Both compilers are more than just users, they're direct contributors 7

8 Common Projects GAS supports more formats than GCC can output (ex. UAL) This is great for LLVM, that only outputs UAL asm LD/Gold's support for LTO has been done by both sides Healthy discussions on both lists (e)glibc is completely separate LLVM should be compatible with any libc available Multilib? IFUNC? Sanitizers should be fairly identical on both sides Only minor build system issues I know of 8

9 Common Goals 9

10 Common Goals User interface Target triples (well, quintuples) are confusing Do we know all variations in the wild? Is it sane to continue using it? Architecture flags (march/mcpu/mfpu/mtune) What are the defaults on each? Tool invocation (compiler driver, ex. -Wa, -Wl, etc) What do we always pass down? What do we need explicit -Wa/-Wl? Target description should default to similar features 10

11 Common Goals Shouldn't we agree on a common user interface? It would make users' lifes easier by avoiding changes to build systems, scripts etc. It would allow for better integration of the existing tools and simpler driver It should help produce compatible code without resorting to various tool-specific architecture flags How? Drivers are responsible for the magic, front-ends can be a lot more strict Legacy can still be around (in the driver), even with new interfaces 11

12 Standardization 12

13 Standardization What? What's not covered by standards or ABIs How? With the same interface and behaviour, even if the default behaviour is different Ex: LLVM defaults to validate inline asm, GCC doesn't A flag -f{no-}validate-asm changes behaviour Compilers are free to not implement, as long as they recognise and warn that it's not implemented 13

14 Standardization Common extensions Attributes C/C++ extensions (avoid this at all costs) Builtins ASM Frame pointer setup (sp+4 vs. sp on ARM only) Linker API LTO symbols Linkage types (weak, ODR) 14

15 Standardization Inline assembly Syntax & mneumonics (and better docs!) Validation & associated behaviour (.thumb/.arm) General behaviour (less likely, less important) Warnings Hackery support (eg. VLAIS & nested functions) Most wrongly abused undefined behaviour 15

16 Standardization Discourage hackery Stronger warnings, errors, checks Strongly deprecate bad ideas (VLAIS, nested functions) Add warnings for extension usage Warn on any non-standard/abi usage Maybe warn on non-agreed extensions by other compiler? Possibly suggest better ideas? (clang does a bit of that) 16

17 Take aways Both compilers will be relevant for the foreseeable future We agree on most technical decisions, but not all We should share technical solutions, not legal or political Users shouldn't be penalised by our healthy competition But we don't have time to implement the same features at the same time (nor should we!) Therefore... Agreeing to user-facing standards and changing our roadmaps (not our current plans) to them, seems only logical 17

18 Thanks! 18

19 References LLVM collaboration: Zero-cost toolchain "standardization" process: Steps to diversity in your open source group 19