[SAoC] MLIR Support for LDC
Stefanos Baziotis
sdi1600105 at di.uoa.gr
Wed Sep 25 10:42:46 UTC 2019
On Wednesday, 25 September 2019 at 01:47:43 UTC, Roberto
Rosmaninho wrote:
> Hi everyone, I'm responsible to implement MLIR support to LDC,
> just in case you missed my presentation post about the project
> this is the post that I wrote last week:
> https://forum.dlang.org/thread/hinceoqtdfcxhahbuwru@forum.dlang.org
>
IMO, it's better to keep updates on one thread (e.g. your
presentation thread).
That way, one can open only one thread and see all the history.
>
> For now, I have just two questions:
> I've already started to play with LDC source code but I still
> don't know how to run and test the modifications that I
> writing. How can I see a "printf" that I put in a file just to
> test a variable?
> How is the best way to debug LDC on MacOS? And how to enable
> all flags of debug and log?
So, if you just want to print something for debugging purposes,
you can just use printf. However, I would recommend getting used
to
Logger utilities. Let me explain:
You can see across LDC this "Logger" thing everywhere
There is code like:
IF_LOG Logger::println("InterfaceDeclaration::codegen: '%s'",
decl->toPrettyChars())
(That specific code is in visit(InterfaceDeclaration) in
declarations.cpp).
These work like printf but with some added features. First, if
you put
this IF_LOG thing in the front, then the message is printed only
if logging
is enabled (don't worry, I will explain how to enable logging).
Otherwise,
always of course. That helps so that you can leave logging info
around
(when done debugging and you feel that there's something that is
useful
to be printed when one requests a log).
The second thing which for me is super smart and useful is that
these
utilities have a sense of scope. Think of this example:
void b() {
Logger::println("roberto2");
}
void a() {
Logger::println("roberto1");
b();
}
With normal printf, you would see:
roberto1
roberto2
But with Logger::println, you see:
roberto1
* roberto2
Notice the indentation and the star. ;)
That is super useful because it decouples messages and helps you
pinpoint
where your message is in the bigger picture.
(That thing btw is controlled with LOG_SCOPE which you will also
see
around and you can learn more about how it works either by just
grepping
it or reading this [1]).
So, now that you have a nicer way to print, how one enables
logging?
Logging is of course useful not in order to see _your_ message,
but all the
other messages and how yours is placed among them.
There are 2 kinds of logging (that I am aware of. I'm pretty
happy with the second
so I didn't search more).
The one is -v which is "Verbose". What that means basically is it
logs
info not for the LDC programmer but for the LDC user, who happens
to care
to see some specific info about what LDC does.
There is also -vv which has a weird description but basically
means: "Info
for the LDC developers that care about the internal things that
happen".
You can see these and all the other options here [2]
You probably want the second, -vv. Since we're on the subject,
the other
thing you probably will like is -output-ll which outputs the LLVM
IR.
You may even end up to put a specific flag for MLIR. But for the
time being,
seeing the LLVM IR I think will help.
Lastly, the usual workflow for LDC is Johan's workflow [3].
You don't necessarily want to follow this for _every single
change_. That will
kill productivity and it's already kind of boring to wait for
compilation
when you change even a single variable.
What you probably want though is having a specific (or a bunch of
specific)
test case that you run (instead of running the whole suite)
continuously.
and _definitely_, you run the whole suite when you're done. I'd
suggest
to run it every so often, I usually do it every 10-20 "small"
changes.
Now, notice this note I have added on the bottom of the page:
Note: `ninja` builds the whole LDC suite. Most of the time,
you'll want to only rebuild the ldc2 binary. You can do that with
`ninja ldc2`.
So, when you do a change on a single file, you want to do `ninja
ldc2`. Trust me,
this is day and night in how much time it takes to compile.
Unfortunately, I can't give you any info about MacOS because I
have not used
one for any serious programming. I _think_ David Nadlinger
uses Mac but I may very well be wrong.
AFAIK, you can have GDB. My guess is that Mac will have a more
Visual Studio kind
of debugger because the terminal interface of GDB is just
nerve-racking.
But since it's better than nothing for some situations, if I
can't target
something easily, I do "info functions" while first I have made
gdb output
to a file and then I grep this file for function that I want.
This is
more complicated than you would expect because of name mangling
and stuff.
I described this very roughly since I don't know if you're
interested. Let
me know if you, but I would also recommend to ask Mac users for
more info.
Lastly, make sure you have read this page [4] and that you have
installed
LLVM and LDC with -DCMAKE_BUILD_TYPE=RelWithDebInfo. And bear in
mind
that LDC debug info is not the best :).
Best of luck,
Stefanos Baziotis
>
> I'm currently working on irstate.* and declarations.cpp, any
> tips or warnings about these files?
>
> Regards,
> Roberto Rosmaninho
[1]
https://forum.dlang.org/post/xbfsztzkrqtxmfgcflug@forum.dlang.org
[2] https://wiki.dlang.org/Using_LDC
[3]
https://wiki.dlang.org/LDC_Lit-based_testsuite#My_workflow_when_working_on_LDC_.28Johan.29
[4]
https://wiki.dlang.org/Building_LDC_from_source#Building_LLVM_manually
More information about the Digitalmars-d
mailing list