This is an archive of the discontinued LLVM Phabricator instance.

[DebugInfo] Fix emitting DWARF64 type units (10/19).
ClosedPublic

Authored by ikudrin on Sep 2 2020, 6:22 AM.

Details

Summary

The patch fixes emitting the offset to the type DIE. All other fields are already fixed in previous patches.

Diff Detail

Event Timeline

ikudrin created this revision.Sep 2 2020, 6:22 AM
ikudrin requested review of this revision.Sep 2 2020, 6:22 AM
dblaikie accepted this revision.Sep 2 2020, 9:43 PM

Looks good.

General feedback: If you can include the original C source code and whatever compile command was needed to generate the IR in any tests (this includes other patches I've already approved, if possible - not vital, many of the tests have very small IR that's pretty easy to read, but it's a "nice to have") that'd be handy! Makes it easier to eyeball the dump output and understand what it's expecting.

This revision is now accepted and ready to land.Sep 2 2020, 9:43 PM

General feedback: If you can include the original C source code and whatever compile command was needed to generate the IR in any tests (this includes other patches I've already approved, if possible - not vital, many of the tests have very small IR that's pretty easy to read, but it's a "nice to have") that'd be handy! Makes it easier to eyeball the dump output and understand what it's expecting.

The test sources were based on some simple code, but then they were cleared as much as I could. I guess they may be considered artificial. Do you think it will be beneficial to add the code like the following here?

struct Foo {int a;};
Foo foo;
ikudrin retitled this revision from [DebugInfo] Fix emitting DWARF64 type units (14/19). to [DebugInfo] Fix emitting DWARF64 type units (10/19)..Sep 3 2020, 7:42 AM

General feedback: If you can include the original C source code and whatever compile command was needed to generate the IR in any tests (this includes other patches I've already approved, if possible - not vital, many of the tests have very small IR that's pretty easy to read, but it's a "nice to have") that'd be handy! Makes it easier to eyeball the dump output and understand what it's expecting.

The test sources were based on some simple code, but then they were cleared as much as I could.

You mean the IR was modified after compilation? Or that the original C source was simplified as much as possible?

Usually we don't simplify the IR - not worth it/doesn't make things especially more maintainable & more likely to introduce something that makes the IR quirky/not representative of the normal Clang generated IR.

I guess they may be considered artificial. Do you think it will be beneficial to add the code like the following here?

struct Foo {int a;};
Foo foo;

Yep! Nice and simple bits of stuff like that are great/handy to have!

The test sources were based on some simple code, but then they were cleared as much as I could.

You mean the IR was modified after compilation? Or that the original C source was simplified as much as possible?

I removed/adjusted some attributes here and there to make the tests smaller and to express mostly what I wanted to test in each particular case. In some cases, like the test for .debug_macro, the source was created fully manually, based on existing tests.

Usually we don't simplify the IR - not worth it/doesn't make things especially more maintainable & more likely to introduce something that makes the IR quirky/not representative of the normal Clang generated IR.

I'll see if I can update the tests in the series so that the IR is fully generated by clang.

The test sources were based on some simple code, but then they were cleared as much as I could.

You mean the IR was modified after compilation? Or that the original C source was simplified as much as possible?

I removed/adjusted some attributes here and there to make the tests smaller and to express mostly what I wanted to test in each particular case. In some cases, like the test for .debug_macro, the source was created fully manually, based on existing tests.

Usually we don't simplify the IR - not worth it/doesn't make things especially more maintainable & more likely to introduce something that makes the IR quirky/not representative of the normal Clang generated IR.

I'll see if I can update the tests in the series so that the IR is fully generated by clang.

Cool cool - use your best judgment, if the only pure Clang IR you can get is way more complicated than the hand-crafted/tweaked version (and the latter is simple enough in absolute, not just relative, terms to be fairly legible by itself) - the hand-crafted/tweaked version might be the better call. I imagine for macros this may be the case. Though I /thought/ I made it so a compile unit couldn't be emitted if it had no code/data in it - if that's the case, I'm not sure there's much simplification available in a macro test case compared to what clang would generate (& I'd use the simplest thing I can imagine to keep the CU live: "extern int i; int i;") - but if it can be done even without that, great!

This revision was landed with ongoing or failed builds.Sep 14 2020, 10:25 PM
This revision was automatically updated to reflect the committed changes.