Re: Is this Forum Moderated?

["Dan'l Miller" <optikos@verizon.net>]

On Monday, May 21, 2018 at 6:40:14 AM UTC-5, Brian Drummond wrote:
> On Sun, 20 May 2018 09:18:15 -0700, Dan'l Miller wrote:
> 
> 
> > 
> > There is a fair chance that LLVM already has all the primitives needed
> > to express every conceivable Ada construct and semantics.   (GNAT didn't
> > have to extend GCC's C IR very much over all these years; there have
> > been 10 tree types added to GCC's C IR for Ada topics, and even 6 of
> > those have varying degrees of ‘it never actually shows up in the tree
> > downstream from GIGI’.)
> 
> One it doesn't have : support for nested subprograms. It's too heavily 
> modelled on C.

  Well, Clang supports C++11, C++14, C++17.  C++11 has lambdas that can be assigned to a named local variable, which is substantially the same feature, not in the language per se, but as an idiom nowadays.

http://clang-developers.42468.n3.nabble.com/Nested-functions-in-Clang-tp4047603p4047605.html

auto const local_function = [&](int parameter) {
  // Do something
};
...
local_function(1);

so GELI (GIGI-alternative Emits LLVM IR, the LLVM-based alternative to GIGI in GNAT) would emit the LLVM bitcode IR that Clang today already emits there.

Steps on the road to GNAT's GELI as an alternative to GIGI:
0) To design and author GELI, the LLVM-facing rear of the Clang front-end would be borrowed in general.
1) On a per tree-node type in GNAT's Ada-IR tree (i.e., whatever snippet of work that the iterator/cursor traversing GNAT's fully-semantically-adorned Ada-IR tree bites off for GIGI to chew on), GELI would first borrow the corresponding C++ language feature's LLVM-bitcode-IR generation code…
2) … then compare that starting point to what GIGI transduces into the C-IR tree for GNAT to find semantic adornments in the Ada-IR tree that were not covered …
3) … then ponder whether C++ or any non-C language has any additional delta of semantics not already covered by GELI's LLVM-bitcode-IR generation for that snippet …
3.1) if yes,
3.1.1) then borrow from that language's corresponding LLVM-bitcode-IR generation code;
3.1.2) then compare GELI's evermore-evolved LLVM-bitcode-IR generation for that snippet with what GIGI transduces into the C-IR tree for GNAT; go to step 3.
3.2) if no, then author fresh LLVM-bitcode-IR generation code from scratch; go to step 3.
4) If more snippets of GNAT's fully-semantically-adorned Ada-IR tree remain without LLVM-bitcode-IR generation in GELI, go to step 1.
5) Release GELI-based/LLVM-backended GNAT corresponding to a major.minor FSF GCC release.
6) If new language features or bug-fixes were released into FSF GNAT for the next GCC release, go to step 1.
7) Maintain this GELI fork of GNAT indefinitely until accepted* into GCC or until something like GELI is released into FSF GNAT by AdaCore**.

* which could conceivably be never, given that GELI requires the entirety of LLVM to be wholesale imported into GCC to comply with the Target Code clauses of GPLv3 and the Eligible Compilation Process of its Runtime Exception

** which, post-Dewar, might or might not have enough sway with RMS himself to pull off the idea of importing*** the entirety of LLVM into GCC merely for GNAT's needs.

*** or AdaCore could conceivably opt (in the publicly-released-to-FSF GNAT source code) to emit IR from GCC for downstream processing by a separate nonGPL-licensed LLVM executable, thus triggering the ••••LLVM-produced machine code downstream to strictly be full-fledged GPLv3-licensed•••• due to not satisfying GPLv3's Target Code clause and likely not satisfying Runtime Exception's Eligible Compilation Process clause either.  And then customers who pay for GNAT Pro would not rely on that every-LLVM-target-must-be-GPLv3ed version; they could conceivably get & rely on something more resembling GELI('s satisfaction of the Target Code and Eligible Compilation Process clauses), so that AdaCore's customers would not need GPLv3-license all their LLVM-target executables and libraries.  If past track record predicts future regarding post-3.15p GNAT, then this third *** variant might be the most likely, unless RMS himself is displeased with even emitting LLVM IR at all from GCC.

(If RMS would be displeased by even the slightest whiff of LLVM & LLVM's bitcode IR anywhere near GCC [which •seems• to be the read-the-tea-leaves current vibe], then the current status quo is the most likely:  no LLVM machine-code generation from FSF GNAT whatsoever, other than the one-off DragonEgg experiment.)

> I believe  this was one of the problems Dragonegg was facing.

Looking through DragonEgg's source code reveals that borrowing the LLVM bitcode IR for C++11's assigning a lambda to a named local variable is the least of the problems that DragonEgg's stick-fingers-into-far-too-many-pies design was facing.

> The GHDL project already faced this, when translating its own IR 
> ("ortho") to the LLVM backend, and overcame it successfully, so it's not 
> a total showstopper

Clang also already faced this for C++11, as shown above.

> I haven't dived into src/ortho/llvm in the ghdl source tree to find out 
> how Tristan did it.

The authoring of GELI will require looking at the LLVM-backended open-source compilers for Clang, Flang, Haskell's GHC, Rust, GHDL, and so forth to harvest GPLv3-compatible-licensed source code inspiration from which to borrow, wherever analogous language features or analogous higher-order-usage idioms of lower-language features can be found in other languages.