[cfe-dev] [GSoC 2014] Project RFC

[Gavin Howard]

Romanov,

Thanks for the quick reply.

> I do not see the benefits you are talking about. LLVM is a huge
> project with lots of contributors, not that new ones are not welcome.
> But, I would not showcase it as a highlight.

I can definitely see your point. I explained it as best I could above
that list by saying

>> In other words, I fully intend to become acquainted with LLVM's internals and
>> become a regular contributor. Writing a frontend would be a nice way for me to
>> do that without having to learn the entire LLVM infrastructure all at once (and
>> ask endless questions that would drive any mentor crazy).

Let's face it, every useful open source project has a big code base.
It's hard to get acquainted with it.

But more seriously, I know that one more contributor is really not
that appealing. I sometimes forget that, though; LFyre is my own
project, and I can't tell you how nice it would be to add another
contributor! But LLVM could definitely make it by without me. Again,
this is a long-term benefit. And to be honest, since I will be writing
an LLVM frontend anyway, this is not that great of a reason, other
than to have someone, who would have been a mentor anyway, make sure
that some young buck learns the ropes and becomes a good contributor.
I have no idea what I will contribute in the future, but I definitely
hope it would be worthwhile.

You can scratch this reason if you want, but I'll leave it up there,
just in case.

> What is the biggest idea in your front-end? What is the main selling
> point? Please be qualitative here.

The selling point is the language, which I explained in many words
below the list of benefits. Like I said, it's inherently difficult to
explain the benefits of a language. We already have some, so why do we
need another? Unfortunately, it's hard to see the benefits, and I'm
not going to give another gushing list of features like I did in the
RFC. Really, it's up to you to judge, and if your judgment is that
there isn't much benefit, then that's what it is; I can't really
change that.

There is also the fact that as this becomes the compiler for LFyre,
and LFyre gets some real users, LLVM will benefit from having more
users. Yes, I know that this benefit is far off, but it's there.

> What new capabilities do you have in mind and which are currently
> missing from LLVM?

I mentioned one above the short list of benefits, which was extending
lld to link compiler-generated metadata across packages. LFyre's
reflection system is pretty intense, and it requires access to all, or
nearly all, the metadata generated by the compiler. Currently, there
is not a linker that can do what it needs (that I know of; I may be
wrong).

The other answer is that I can't anticipate every new capability that
LLVM would need to accommodate LFyre. I only know of the one I listed
above, but there may be others, such as handling macros (although I
doubt it because there's a Scheme frontend).

There is, however, some special optimizations that I may want for
LFyre. One of them deals with the fact that LFyre exclusively uses
"fat pointers" for memory safety. LFyre is pass-by-value only, so
those pointers would be copied before they are passed around as
parameters. One optimization that I may be able to add is figuring out
when just passing the stack address of a local pointer would be okay
and doing that instead of passing a full fat pointer, thus doing one
copy instead of three. And since LFyre actually uses pointers, I would
bet that it would become good programming practice to pass a pointer
instead of a whole object, and thus happen quite often. So reducing
the overhead when passing pointers may be important, and any progress
I make there will go directly into LLVM.

I also don't know how in depth LLVM's optimizations are for virtual
methods and interfaces, but I have an idea or two there. And that's
important to me because LFyre's object system is completely made of
structs and interfaces. It will be crucial to heavily optimize method
resolution. In fact, it will be crucial for users to be able to pick
between fast calls or low memory use, something that I would have to
take into account.

In fact, any optimizations I need will end up in LLVM. I see no reason
to add them to the frontend itself.

So the real answer is "I don't know." But I hope that the ideas I
listed above give you some idea of what LFyre may need, and therefore,
what LLVM may get.

And as a final hurrah, as I finished the RFC, I mentioned that I am
interested in an LLVM project, even if it's not a frontend for LFyre.
I think starting the Universal Driver would definitely be a fun
project, as well as practice for later when I build up LFyre's
toolchain. So doing a frontend is certainly not the only option,
although it's definitely WAY at the top of my list. I'm really
attached to this little language of mine, and I want to see it
actually succeed, but LLVM has its needs to. And I can certainly put
my attachments aside to make sure I have an income from a fun job this
summer.

God Bless,
Gavin Howard