[llvm-commits] [PATCH] Preserve DebugInfo during LICM

[Török Edwin]

On 2009-10-13 20:16, Devang Patel wrote:
> 2009/10/11 Török Edwin <edwintorok at gmail.com>:
>   
>>>> I think that we'd need another TEST.dbgquality that tests whether each
>>>> basicblock has at least one stoppoint (if original did),
>>>> and also outputs how many instructions have a stoppoint in same BB, how
>>>> many have a stoppoint
>>>> foundable by findStopPointInst, and how many don't have at all. The test
>>>> would pass if each BB has at least one stoppoint,
>>>>         
>>> I'm not sure what the right approach is here.  When stoppoints move to
>>> being on the instructions, we won't really need this.
>>>       
>> We'd need something else:  check that each insn has a debug info, some
>> optimizers may create new instructions and forget
>> to set debug info.
>>
>> But you're right, there is no point working on this now, since the debug
>> info is about to undergo a major change.
>>
>>     
>
> Now, debug info (location info) is attached to an instruction. There
> is a way to check this.
>
>   MetadataContext &TheMetadata = ...getContext().getMetadata();
>   unsigned MDDbgKind = TheMetadata.getMDKind("dbg");
>   if (MDNode *Dbg = TheMetadata.getMD(MDDbgKind, I)) {
>   

Maybe I should update findStopPoint to return dbg metadata instead of a
stoppoint, if stoppoints are going away?

If stoppoints are going away please let me know so I can update
Analysis/DbgInfoPrinter.cpp too.

> Here Dbg is non-null if debug info is attached with instruction I.
>   

Does llvm-gcc and clang support emitting dbgmetadata on instructions?
If yes I'll start working on something that measures quality of dbginfo
in the testsuite, and maybe do some checks too.

Also does this move to metadata on instructions fix the
linker/inliner(?) bug where the line number was greater than the total
lines in the file?
And the bug that you can't link together multiple files with debug info
due to multiple main compilation units?

Best regards,
--Edwin