-
Notifications
You must be signed in to change notification settings - Fork 18
/
README.dragonegg
48 lines (37 loc) · 2.11 KB
/
README.dragonegg
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
Why not DragonEgg?
------------------
If you know about the DragonEgg project (https://dragonegg.llvm.org/) then a
natural question is "why starting a GNAT LLVM project from scratch instead of
building on top of DragonEgg?"
From a technical perspective, it's a closer call, but there are a number of
non-technical advantages of our approach:
- We want a "pure" LLVM approach that is as easy to integrate and fit
into the LLVM ecosystem as possible;
- DragonEgg makes the whole technology more fragile: any change in any part
may break things in a potentially hard to identify way
(GNAT+Gigi+GCC+DragonEgg+LLVM vs GNAT+GNAT LLVM+LLVM)
- The GNAT LLVM approach allows us to have code written in Ada instead of
C++ in the case of DragonEgg.
There are also limitations in the current state of DragonEgg, which we'd
have to remove as part of a project based on DragonEgg:
- It hasn't been touched since 2014 (except for
https://reviews.llvm.org/D35667) and as far as Ada is concerned,
supports only LLVM 3.3 and GCC 4.6.
- It only supports x86 and ARM processor families (at least in terms of
supported builtins)
- Debug info support is poor
The technical advantage of a DragonEgg approach is that we could use all
the present "tree lowering" code that's not only in Gigi, but in GCC (for
example, GCC knows how to do a MOD, not REM, operation, but we have to
produce that code from scratch) and we need at least some sort of
intermediate structure between the GNAT tree and the LLVM IR. But a
disadvantage is that DragonEgg's goal and strength is the ability to
support all GCC front-ends and here we are focusing on good Ada support, so
we wouldn't really be taking advantage of this strength. Another
disadvantage is that some concepts (such as alias sets) don't map well
between GCC and LLVM and it's better to directly generate the LLVM style
of the concepts directly from the sources.
Finally, DragonEgg was meant as a way to bring many language front-ends to
LLVM. Since then, all languages supported by GCC have been plugged to
LLVM except Ada, so this would leave DragonEgg Ada specific,
with lots of unnecessary complexity.