llvm dev - Apr 2018 - Why LLVM doesn't have debug information of function right parentheses？

Hi,

On 12/04/2018 15:35, Frozen via llvm-dev wrote:
> I added one attribute named EndLine in LLVM IR before. LLVM's part is 
> not hard, but will modify many places in Clang. I success for it, you 
> can try this way.
> 
For loops, we use a range to keep track of the start and end of the loop 
for remarks: http://llvm.org/doxygen/classllvm_1_1Loop_1_1LocRange.html

Maybe it would make sense to use something similar for function start 
and end locations?

Cheers,
Florian

I really wouldn't be sure this is the right direction to go anyway - as
pointed out, there coudl be a return of a constant which would be a single
instruction & it would make more sense to me to attribute that to the line
where "return" is written, than where the closing brace is.

I think this is, for my money, a legitimate difference in implementations
between GCC and Clang - not a case of one being right/better than the other.

(adding echristo@ so he can speak for some of this if he wants to, since
they were choices made a while back)

On Thu, Apr 12, 2018 at 9:11 AM Florian Hahn via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> On 12/04/2018 15:35, Frozen via llvm-dev wrote:
> > I added one attribute named EndLine in LLVM IR before. LLVM's part
is
> > not hard, but will modify many places in Clang. I success for it, you
> > can try this way.
> >
>
> For loops, we use a range to keep track of the start and end of the loop
> for remarks: http://llvm.org/doxygen/classllvm_1_1Loop_1_1LocRange.html
>
> Maybe it would make sense to use something similar for function start
> and end locations?
>
> Cheers,
> Florian
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180417/9a538b20/attachment.html>

Remembering a discussion as to why we do this from a few years ago: (*makes
note to start writing design decisions this way down somewhere*)

I was in favor of the current method for a few reasons:

a) ensuring that it would "always happen" that we had either a unified
return block or a well propagated location onto return instructions seemed
like it would be difficult to maintain and very subject to optimization
differences.
b) The "always stop at the end brace of the function" seemed weirder
to me
than just being able to say "finish" when stepping in a debugger
c) I worried about profiling information that used debug information being
accurate or ascribing cycles to the closing brace of a function which
seemed to be a loss of fidelity.

Thoughts?

-eric

On Tue, Apr 17, 2018 at 12:26 PM David Blaikie <dblaikie at gmail.com>
wrote:
> I really wouldn't be sure this is the right direction to go anyway - as
> pointed out, there coudl be a return of a constant which would be a single
> instruction & it would make more sense to me to attribute that to the
line
> where "return" is written, than where the closing brace is.
>
> I think this is, for my money, a legitimate difference in implementations
> between GCC and Clang - not a case of one being right/better than the
other.
>
> (adding echristo@ so he can speak for some of this if he wants to, since
> they were choices made a while back)
>
>
> On Thu, Apr 12, 2018 at 9:11 AM Florian Hahn via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi,
>>
>> On 12/04/2018 15:35, Frozen via llvm-dev wrote:
>> > I added one attribute named EndLine in LLVM IR before. LLVM's
part is
>> > not hard, but will modify many places in Clang. I success for it,
you
>> > can try this way.
>> >
>>
>> For loops, we use a range to keep track of the start and end of the
loop
>> for remarks: http://llvm.org/doxygen/classllvm_1_1Loop_1_1LocRange.html
>>
>> Maybe it would make sense to use something similar for function start
>> and end locations?
>>
>> Cheers,
>> Florian
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180417/3e17960e/attachment.html>