[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