This is an archive of the discontinued LLVM Phabricator instance.

[llvm-c] Add the ability to create debug locations
AbandonedPublic

Authored by jketema on Apr 12 2016, 3:22 PM.

Details

Summary

This ability was implicitly removed when debug information got its own specialized meta-data nodes.

Diff Detail

Event Timeline

jketema updated this revision to Diff 53475.Apr 12 2016, 3:22 PM
jketema retitled this revision from to [llvm-c] Add the ability to create debug locations.
jketema updated this object.
jketema added a reviewer: deadalnix.
jketema added a subscriber: llvm-commits.
AlexDenisov added inline comments.
include/llvm-c/Core.h
2790

Would not it be better to name it LLVMCreateDILocation?
This way other methods from the DI family can be imported consistently.
Just a side note though :)

jketema updated this object.Apr 13 2016, 2:39 PM
jketema added inline comments.
include/llvm-c/Core.h
2790

I was trying to match the set and get functions below.

whitequark added inline comments.Apr 13 2016, 2:48 PM
include/llvm-c/Core.h
2790

I second LLVMCreateDILocation suggestion

lib/IR/Core.cpp
2315

Factor out this cast, perhaps? I can see it happenning a lot.

echristo edited edge metadata.Apr 13 2016, 2:52 PM

I'd be really surprised if this debug information worked. To make it work you need DISubprogram metadata which I don't think we want to put in the C API right now - at least not without serious stability caveats.

whitequark edited edge metadata.Apr 13 2016, 2:54 PM

@echristo What about exposing the bare key-value metadata interface? It itself can be stable, and frontends could use it before anything more specific is stabilized.

@echristo Indeed this doesn't quite work: the generated bitcode is parsable, but invalid, because a DIScope cannot be generated. I was planning to expose DIBuilder as a follow up patch, which should resolve this, but given your comment, you think this is not the right time to do this?

deadalnix requested changes to this revision.Apr 13 2016, 3:38 PM
deadalnix edited edge metadata.

Various things here :

  • Typically, there is a LOT of DILoc generated in any non toy module. Wrapping them all in a Value is going to be VERY wasteful. I would vote to add a LLVMMetadataRef type and use it.
  • There is no need to create a new C test for that IMO. The echo test should be extended and a module with lcoation information should be fed to it.
  • How is the scope created using that API ? If the plan is to use the old way to scope instead of DIScope, then I'm not sure where this is going. This allow to mix the old debug API with the new one, while not being able to get the largest benefit in the name a reduced resource requirement.

On a side note I have a patch that wrap the whole DIBuilder thing in the C API, that i did not submitted yet as testing was lacking.

This revision now requires changes to proceed.Apr 13 2016, 3:38 PM

@deadalnix

How is the scope created using that API ?

"I was planning to expose DIBuilder as a follow up patch"

Sorry, missed that bit. OK, let's discuss about how to proceed with this, as it obviously has an impact on this patch.

It seems to me that mapping the new DI API is a good opportunity to introduce LLVMMetadataRef and the MD class hierarchy. Wrapping everything in MetadataAsValue is going to create a tremendous amount of waste. I submitted D19088 , which isn't a a state where it is ready to be merged, but that should help the discussion here.

jketema abandoned this revision.Apr 23 2016, 1:58 AM