[llvm-dev] Email list just for front end developers?

Thu May 11 15:51:14 PDT 2017

On Sun, May 7, 2017 at 6:43 AM, Perry E. Metzger via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Sat, 6 May 2017 21:38:50 -0700 Sanjoy Das
> <sanjoy at playingwithpointers.com> wrote:
> > Hi Perry,
> >
> > On Sat, May 6, 2017 at 2:55 PM, Perry E. Metzger
> > <perry at piermont.com> wrote:
> > >> Let me put it this way -- I'm pretty sure if you take it on
> > >> yourself to answer beginner questions on llvm-dev promptly,
> > >> nobody will *complain*.  In fact, you're going to make some
> > >> folks happy. :)
> > >
> > > Sure, but who will answer mine? Part of the reason I asked about
> > > this was selfish, as I'd like access to other people in the same
> > > situation as me who might know answers. (I don't think the people
> > > here now will want to answer more questions, and many of my
> > > questions doubtless border on inanely stupid but for the fact
> > > that it is hard to find answers in the docs.)
> >
> > I don't see how people who don't have time to answer on llvm-dev
> > will find time to answer on some other mailing list.
>
> My belief was they would be different populations. That is why there
> would be a separate list. The other list would attract mostly front
> end devs. I would expect front end devs would be both more interested
> in a list that discusses mostly things they care about (including IR
> changes they need to be aware of) and more interested in mutual
> assistance.
>
> But never mind, it seems that I'm the only person who likes that idea,
> so we're ignoring that possibility for the moment.
>
> > > That said, I'm willing to give it a try, as an experiment. How
> > > long should we attempt it for? If that's reasonably agreed to,
> > > I'll
> >
> > Depends on how much time you have -- that's the limiting resource
> > here.
>
> By time I meant the question of how long one tries a strategy before
> deciding to look for new strategies. :) Given that few questions about
> front end things arrive on the -dev list, trying to help answering
> them, for the moment, will only require that I attend more closely to
> the postings, and that other people make a bit of an effort to answer
> "dumb questions" as well.
>
> Hopefully that will simply work. My skepticism comes from the feeling
> that if it was really going to work, it would have already, but
> there's no reason not to give it a good faith try.
>
> On the wider issue:
>
> LLVM has been transformative. There are now a lot more people
> experimenting with compiling languages than ever before (including
> me!) because LLVM removes a lot of the pain from constructing
> everything past the IR.
>
> However, until I started working with it personally, I didn't
> understand how much work it was to learn how to use it, and much of
> that work is because there is a very big gap between the programmers
> guide + the tutorial (which makes it all look like you can learn the
> whole thing in an afternoon) and what you actually need to figure out
> to get things done. Much of what you need you have to puzzle out
> painstakingly on your own, trying to make sense of the doxygen docs
> and reading code, because there's less written down than one would
> hope. Even the IR language reference, which is seemingly complete at
> first glance, has some big gaps in it.
>
> Given good enough resources, though, even more people could be using
> LLVM to create compilers, which would be a great thing. And,
> selfishly, given better resources, my own work would be easier. :)
> Thus my overall interest.
>

I'm still unclear about what sorts of questions/discussion this audience is
interested in. Can you provide a few examples of questions that might be
asked, or links to discussions/blog posts on the net that exemplify the
type of thing that you would want to happen in the "frontend authors using
LLVM" medium you are thinking of?

For example, looking at the post you linked (
http://lists.llvm.org/pipermail/llvm-dev/2017-March/111526.html the author
of which is in this thread I think, hi!), there's not much LLVM-specific
about it. In order to generate LLVM IR, it is necessary to understand its
semantics. The semantics are mostly C-like, and so the answer to questions
like those in the post:

- How to assign a text to a string variable?
- How to access for example the 4th element in a heap-allocated array?
- How to create local variables which are not part of the global scope?
- How to create complex structures like classes and objects?

is basically "how would you do it in C"? For example, to assign text to a
"string variable", you first have to have a struct that represents you
string type, then you do some C-level code to manipulate that data
structure. For a class with inheritance, you would put a vptr in your
structs and emit vtables. Etc. Then it's just a matter of writing some C
code and running it through Clang to see how Clang lowers it to LLVM IR. It
shouldn't be too hard to then trace back from the textual IR to the API's
(at worst, requiring a small amount of trial and error, at worst looking at
small parts of Clang's source code after grepping for AllocaInst or
whatever).

Something like
https://f0rki.gitbooks.io/mapping-high-level-constructs-to-llvm-ir/content/
might be useful too, though you could get mostly the same effect by looking
at Clang's output.

For some of the specifics of LLVM IR's SSA form (like phi nodes) working
through the Kaleidoscope tutorial should give a feel for how to do it. (for
an intro, a video like https://www.youtube.com/watch?v=haQ2cijhvhE by our
own Chandler Carruth might be useful).

However, from your other posts, you say something like:
"People working on front ends typically don't really know everything
about the innards of LLVM, and thanks to LLVM's very nicely designed
architecture, we don't need to, we mostly need to know how to
generate IR and hook up to the rest of the system."

So it sounds like you're more interested in API usage like IRBuilder,
setting up codegen, setting up MC, configuring pass pipelines, etc.? I.e.
you have a clear idea about the "big picture" and what you are trying to
do, but want to know how that is done in LLVM (e.g. "how do I create a phi
node?"). This is a very different kind of question from the ones above.

On the other hand, "hook it up to the rest of the system" might be
referring to general toolchain knowledge (which is again not LLVM specifc).
For example object file semantics (i.e. the semantics of what comes out the
LLVM backends; there's a lot more to it than just a single blob of machine
code) and how that interacts with the rest of the system (e.g. how a malloc
declaration in LLVM IR gets actually resolved and called at runtime).

I'd really like to hear your feedback. I think that historically, Clang has
been the dominant frontend and so there hasn't been much impetus for
providing certain kinds of documention, but as you mention upthread, there
is now a quite large tail of other frontends that are developed outside of
the LLVM community, so that might have to change.

-- Sean Silva

>
> > However, I liked your idea of maintaining a wiki-like thing.  Both
> > http://llvm.org/docs/Frontend/PerformanceTips.html and
> > http://llvm.org/docs/tutorial/ will be good additions there.
>
> Parts of the programmer's manual
> http://llvm.org/docs/ProgrammersManual.html are also essential, though
> for a front end developer, especially one using the C API, not
> everything is something you want to know, and it isn't initially
> obvious when you need to read closely.
>
> Anyway, given that you would prefer for it not to be an actual wiki,
> what would be lower barrier to entry and Wiki-ish?
>
> (A big issue with the current workflow, I think, is that for outsiders
> submitting documentation updates the process is very heavyweight. Even
> the use of svn vs. git increases the amount of work for casual users.
> It's just not worth it as it stands for someone to say "hey, please
> fix just this one sentence", especially if you've never contributed to
> LLVM before. However, often even single sentence edits improve
> comprehension. Having a low barrier for small fixes is one of the
> reasons Wikipedia grew so fast. Of course, it is also the reason that
> policing Wikipedia takes huge effort, so there's a tradeoff.)
>
>
> Perry
> --
> Perry E. Metzger                perry at piermont.com
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170511/1d75f363/attachment-0001.html>