<body><div style="font-family: 'PingFang SC'; font-size: 10.5pt;">Simon, I also think of the way you did. :-) And from my initial investigation, clang should also has some work(i.e. provide the end location for the "endLine" field of DISubprogram), right?<div><div><br></div><div><div>BTW, Simon, your fork of LLVM is open source or not? If open source, could you give the address of it? </div><div><br></div><div>Thanks<br>
<br>
<div class="-eMc-quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex; display: block;">
<span dir="ltr"><
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">Simon Cook via llvm-dev</a>> 在 2017-08-04 00:10:59 写道:
</span>
<br>
<blockquote class="" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex; display: block;">
<div dir="ltr">
<br><br>On 03/08/17 16:21, Robinson, Paul via llvm-dev wrote:<br>> <br>>><br>>> I have implemented this exact behavior in an out of tree LLVM fork I<br>>> maintain, where one of my users needed this behavior, and it seems to<br>>> work well. What we have done is extend the definition of DISubprogram to<br>>> contain a new field "endLine" which holds the line number of the closing<br>>> brace. A pass late in our backend uses this information to set the<br>>> DebugLoc of return instructions in our programs.<br>> <br>> Interesting. I'd have thought the front end could generate the<br>> return-value expression with the source location of the expression,<br>> and the return instruction itself with source location of the closing<br>> brace. Then it would automatically apply to all targets (and all<br>> debug-info formats).<br><br>This works in most cases. It feels the cleaner solution for its<br>target-independence, and was the first way that I tried to solve this<br>problem. It works, apart from the most trivial of functions.<br><br>The case I'm thinking of is a function that just returns a constant, we<br>only have one instruction to attach a source location to, and ideally<br>would like to associate the lowering of the return value with one<br>location, and the actual return with the other. This is what caused me<br>to switch from a return instruction associated location, to something<br>that I unconditionally set later on in my backend. I suppose the same<br>could occur during some optimizations, and we would still want to<br>recover the location.<br><br>> <br>> Or, if that distinction got lost during some optimization, the<br>> separate source location could be attached during instruction<br>> selection? Hopefully that could also be done in a target-neutral<br>> way.<br><br>Aah, good idea. Having this as part of instruction selection/return<br>lowering sounds like a more appropriate place to set the location<br>generically if it needs resetting, as it should be safe from thereon in.<br><br>Thanks,<br>Simon<br>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:llvm-dev@lists.llvm.org" class="yo-genlink">llvm-dev@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" class="yo-genlink" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div>
</blockquote>
</div>
</div></div></div></div></body>