[PATCH] Do not attach a debug location to code inserted by ARC / API for disabling DebugLocations

[Eric Christopher]

On Mon, Apr 29, 2013 at 9:57 PM, Adrian Prantl <aprantl at apple.com> wrote:
> Hi Eric!
>
> On Apr 29, 2013, at 6:10 AM, Eric Christopher <echristo at gmail.com> wrote:
>
>> Looks like it's working around the return value load/alloca eliding in
>> the code generator? I definitely like a more general way of
>> approaching the problem.
>
> It’s possible that I misunderstood you (let me know) but I don’t think that’s an accurate description. Here’s how I would describe it:
>
> If there is
> 1) only a single, simple return stmt in the function,
> 2) and cleanup code,
> 3) prevent the the ret instruction from getting a debug location that is “above” the debug location of the clean code. If there is no cleanup code, however, we still want the return instruction to get the debug location from the elided alloca.
>
> I agree that it looks like a rather specialized solution, but it’s also a rather special problem.
>

Nod. I think I like this comment:

+  // If the function contains only a single simple, return statement,
+  // the cleanup code may become the first breakpoint in the
+  // function. To be safe set the debug location for it to the
+  // location of the return statement.  Otherwise point it to end of
+  // the function's lexical scope.

More than the second paragraph of your commit message btw.

>> I wonder if we can either localize this fix into EmitFunctionEpilog
>> (couldn't come up with one) or if this has applicability in the > 1
>> return statement condition. Open questions, this is a bit of a finicky
>> and complicated area as you've no doubt realized. :)
>
> No doubt :-)
>
> I believe that we cannot localize the patch into EmitFunctionEpilog: If there is cleanup code, we (I?) want the cleanup code to get the line number of the return statement, because it will be the first breakpoint opportunity in the function, and we must keep it, because the user might want to inspect the value of arguments that will get cleaned up. We can only do this in FinishFunction.
>
> In the case of multiple returns the problem with the cleanup code being the first breakpoint in the function should not exist, because there should be some other statement with a debug location before any return statement.

*nod* I think it's just that I'm hoping there's some magical
generalized solution if we sit down and look at it. That said, this is
pretty clean so go ahead.

Thanks for spending the time.

-eric