[llvm-dev] Why LLVM doesn't have debug information of function right parentheses?

Simon Cook via llvm-dev llvm-dev at lists.llvm.org
Thu Aug 3 09:10:59 PDT 2017



On 03/08/17 16:21, Robinson, Paul via llvm-dev wrote:
> 
>>
>> I have implemented this exact behavior in an out of tree LLVM fork I
>> maintain, where one of my users needed this behavior, and it seems to
>> work well. What we have done is extend the definition of DISubprogram to
>> contain a new field "endLine" which holds the line number of the closing
>> brace. A pass late in our backend uses this information to set the
>> DebugLoc of return instructions in our programs.
> 
> Interesting.  I'd have thought the front end could generate the
> return-value expression with the source location of the expression,
> and the return instruction itself with source location of the closing
> brace.  Then it would automatically apply to all targets (and all
> debug-info formats).

This works in most cases. It feels the cleaner solution for its
target-independence, and was the first way that I tried to solve this
problem. It works, apart from the most trivial of functions.

The case I'm thinking of is a function that just returns a constant, we
only have one instruction to attach a source location to, and ideally
would like to associate the lowering of the return value with one
location, and the actual return with the other. This is what caused me
to switch from a return instruction associated location, to something
that I unconditionally set later on in my backend. I suppose the same
could occur during some optimizations, and we would still want to
recover the location.

> 
> Or, if that distinction got lost during some optimization, the
> separate source location could be attached during instruction
> selection?  Hopefully that could also be done in a target-neutral
> way.

Aah, good idea. Having this as part of instruction selection/return
lowering sounds like a more appropriate place to set the location
generically if it needs resetting, as it should be safe from thereon in.

Thanks,
Simon


More information about the llvm-dev mailing list