[LLVMdev] RFC - Adding an optimization report facility?

Tobias Grosser tobias at grosser.es
Mon Mar 10 02:35:10 PDT 2014


On 03/07/2014 03:16 PM, Hal Finkel wrote:
> ----- Original Message -----
>> From: "Diego Novillo" <dnovillo at google.com>

>> Why not just using the line table in -gline-tables-only? These
>> reports will need to latch on arbitrary instructions, not just loop
>> headers. As more transformations use the infrastructure, they will
>> want to emit the report on whatever instruction they triggered on.
>
> I'd prefer that we not do that; although we can certainly use debugging information to enhance the reporting (to include variable names and the like). I prefer the 'srcloc' on loops solution for two reasons:
>
>   1. It does not force users to include debugging symbols just to get optimization reports and, more importantly,
>
>   2. Using srcloc is more accurate: If we include only line table information then we miss column information, and so we can't correctly identify a loop with multiple loops per line (and those that arise from macro expansion). This is a real deal-breaker for me.
>

This is an interesting discussion to have. I currently use line-table 
debug info and this work very well, with the only exception that 
line-table information currently needs to be enabled manually. As this 
could probably be enabled automatically for the users, this does not 
seem like an unsolvable problems.

Using srcloc sounds like an interesting alternative, but I have some 
questions.

1) How does this work with LTO?

Do soclocs actually store information about the source file? Or just the 
offset?

2) Why are soclocs better when macro-expanding?

I really have no idea. A brief explanation not may be sufficient.

3) What about implicit loops e.g. ->begin, ->end

Can we even emit soclocs for implicit loops e.g. formed by C++ iterators 
or range loops?

4) Does the preserving behavior of socs differ from debug
    info?

Will they also be kept on 'best effort'?  Do we need all passes (e.g. 
loop rotate) to preserve socs similar to debug info?

Thanks,
Tobias



More information about the llvm-dev mailing list