[llvm-commits] [PATCH] Introduce -dbg-quality test

[Török Edwin]

On 2009-10-21 20:23, Devang Patel wrote:
> Hi
>
> 2009/10/21 Török Edwin <edwintorok at gmail.com>:
>   
>> Hi Devang,
>>
>> I've written the -dbg-quality pass (attached), and the
>> TEST.dbgquality.Makefile that tests the optimized (-std-compile-opts)
>> bitcode file.
>>     
>
> This is great. Could you explain how you qualify debug info to get the
> following score ?
>   

It is based on a ratio, so it is not affected that much by optimizers
introducing/deleting instructions.
First a score is calculated like (all is all instructions except alloca
and dbginfo intrinsics):
100000.0*debug_info_in_same_BB/all +
10000.0*debug_info_in_previous_BB/all +
100.0*debug_info_on_instruction/all

This score is then normalized so that the maximum score for a module is
always 10000, so that the score doesn't depend on the size of the module.

I think I should also make a final adjustment, to make sure that the
score is 10000 only if original score == maxscore,
currently due to rounding you can get a 10000 score if score is very
close to maxscore (but not equal) too.

The score numbers are arbitrary, I chose 10000, because it would be
equivalent to 100.00%, but since we can't represent fractions in
statistics I multiplied by 100.

I handle both debug metadata and dbg intrinsics. If the intrinsics are
going away then I can remove that part.

>   
>> Should I also add a -std-link-opts tests?
>>     
>
> Yes.
>   

Ok, I'll do that tomorrow.

I thought to also update TEST.dbgopt and TEST.ipodbgopt to show a
summary, but those seem obsolete now that the dbginfo is attached to the
instructions themselves,
or are they still useful for dbg.variable intrinsics? If those are
switched to metadata by llvm 2.7, then probably not.

>   
>> I think some
>> passes (such as -ipsccp) are only run there?
>> I've attached the results, the maximum score is 10000 (meaning all
>> non-alloca/non-dbgintrinsic instructions have debug info).
>> We have 79 tests at 10000 quality, the rest are between 5331 - 9999.
>>
>> I've also found a bug: static constructors/destructors have out-of-file
>> line numbers often (PR5270). I've added a hack in -dbg-quality for now
>> that ignores those functions (denoted by a FIXME).
>>     
>
> I'll take a look at this PR.
>   

Thanks, there is also PR5246 which prevents debug info from being used:
llc crashes when present.
Unfortunately bugpoint is not able to further reduce the testcase, it
may somehow depend on the order of functions in the bitcode.

>   
>> OK to commit, or should I wait till PR5270 is fixed so I can drop the
>> ugly hack?
>>     
>
> I do not think Analysis is a good place for this and DebugInfo as
> well. 

Sure I can move it if needed, but can we have passes in Support/?

> I think, DebugInfo is in Analysis, because we do not want it in
> VMCore. IMO, debug info related code should be in lib/Support. Chris,
> what do you think ?
>   



Best regards,
--Edwin