Re: Suggestions for Improvement in Godbolt for Clang

22 views
Skip to first unread message

Matt Godbolt

unread,
May 6, 2020, 10:08:14 PM5/6/20
to Stefanos Baziotis, compiler-explo...@googlegroups.com
Hi Stefanos!

Thanks so much for your email. I'm going to CC our mailing list: Compiler Explorer is mostly driven by discussion on Slack and on github these days but we do have a mailing list too!

My thoughts:

1: I'm mildly against adding potentially surprising default options. I'm not really sure what `-fno-discard-value-names` does to code generation outside of llvm: if there's a chance it'll ever make a difference then I think it's not a good idea to add. You're right about the user not knowing about this arg, but the user also probably doesn't know about `-emit-llvm` in that case either (does it only affect llvm output?) I could be persuaded otherwise though :)

2) There is a patch coming soon to show instruction selection dags: https://github.com/mattgodbolt/compiler-explorer/pull/1952 -- that might be useful? As for the existing ASM CFG viewer, it's a fantastically useful view but needs a bit of work to unify the asm parsing with the rest of the system. We obviously support a ton of architectures and we do it mostly with smoke and mirrors instead of "really" parsing instructions etc. The hacks need to be updated for LLVM.

We'd gladly accept any help: all the code is on github, and we hang out on the cpplang slack in #compiler-explorer_development so if yo ucan join us in either place we can help!

many thanks, Matt :)



On Fri, May 1, 2020 at 9:18 PM Stefanos Baziotis <stefanos...@gmail.com> wrote:
Hi Matt again,

I hope you are well and healthy!

I thought of 2 ideas that I think are going to make the experience of compiling with
Clang in Godbolt better:

1) fno-discard-value-names by default

It seems that you're using release builds of Clang in godbolt which makes sense.
Release builds however, have (sort of) -fdiscard-value-names set by default.

This means that if we emit LLVM IR, all the values and BB labels have auto-incremented
printed values (%0, %1, ...). I think this makes the LLVM IR quite harder to read for no actual
reason.

If you agree, I think you can make the experience better using one of two simple solutions:
a) Use source builds. That may not be that efficient (to deploy) but these give the best naming.
They obviously have other benefits.
b) The easiest is to pass -fno-discard-value-names (https://godbolt.org/z/iv4UoW) by default, or give an option for the user to enable it (Note that even if it's passed by default,
the user can pass -fno-discard-value-names to disable it).
You might say but well the user can just pass it but actually, it's quite
possible that the user does not know that this cmd arg even exists.

2) Graph output of LLVM IR

I saw this option a couple days ago and oh my god how amazing it is for ASM.
Thank you so much for enabling this!

I was thinking that maybe this can be enabled in LLVM IR. I don't know if I'm doing
something wrong but when I use Graph Output for LLVM IR, it opens only one BB at a time.

The weird thing is that it seems to identify BBs correctly, but we can only see one at a time
and there are no connections.

How easy would be to improve that ? If I can help, please tell me.
I was thinking that even if we can't support all the terminators (switches etc.) at least
at the start, supporting the ones used 99% of the time, i.e. (un)conditional branches, should be
plausible.

As a side note, LLVM has the -view-cfg option that lets you view the CFG
graphically but it's not very convenient honestly. Using godbolt (like with ASM) should be orders
of magnitude better.

Kind regards,
Stefanos Baziotis


--
Matt

Stefanos Baziotis

unread,
May 7, 2020, 9:29:11 AM5/7/20
to Matt Godbolt, compiler-explo...@googlegroups.com
Hi Matt,


> I'm going to CC our mailing list: Compiler Explorer is mostly driven by discussion on Slack and on github these days but we do have a mailing list too!
Thank you!

1) Regarding the first suggestion, I'm sorry that I didn't follow-up with a correction. It's actually a bad suggestion I think. Not because it does anything to code generation. For example, you can take any LLVM IR generated by clang and rename
the values ("registers", basic blocks etc.) any way you want and to LLVM it's pretty much the same code. _Except_ if you use integer arithmetic names e.g. %0, %5, %78 (any other name, like %while, %_0, etc. is ok and as I said, makes no difference).
The problem is that if one uses integer names like those generated by default, then these have to follow strictly the LLVM convention because they're considered unnamed
(https://llvm.org/docs/LangRef.html#identifiers -> check point 3 on the bottom, i.e. Unnamed temporaries are numbered sequentially ...).
Which means that if you are to rename default-generated LLVM IR, to be on the safe side, you have to rename _all_ the values, so that no value is considered unnamed and hence LLVM won't care about its name.

Which brings me to the fact that unfortunately `-fno-discard-value-names` won't rename _all_ the registers. This is not a problem if you're just viewing the IR but it is if you then want to copy it and pass it to LLVM.
That basically means that the only safe solution (that I know of) is to use a source build, which I would be very happy to see in say only the latest version, not all of them. But again, I understand that this might not be realistic.

2) ISel DAGs are great and kudos to the author! Actually I haven't thought that this might be useful in a lot of circumstances. I think though that LLVM IR CFG viewer is useful in its own special way.
I see that in this patch, the author uses graphviz and renders .dot files. -view-cfg (https://llvm.org/docs/Passes.html#view-cfg-view-cfg-of-function) that I mentioned in the previous mail generates .dot files that one then renders with graphviz :)
And those .dot files contain the CFG of a function :) If the ISel can be done, then leveraging -view-cfg should be way easier.


> We'd gladly accept any help: all the code is on github, and we hang out on the cpplang slack in #compiler-explorer_development so if yo ucan join us in either place we can help!

Definitely, I would be very glad and I'll try to find some time to work on this ! I tried to join on the cpplang slack, but it seems to have frozen. I went here: https://cpplang.now.sh/
clicked "Get my invite", then "no_perms" appeared in its place which I clicked and then nothing. If there's a way to join, I'd be very happy!

Best,
Stefanos Baziotis
Reply all
Reply to author
Forward
0 new messages