[PATCH] Internal option to warn on a given stack size.

[Evan Cheng]

I agree hooking this to a clang warning and extending it would be ideal. But before we can get there, is there a strong argument against this internal warning? 

We are in the same road with clients requesting data about stack usage. We figured it's useful to get it into trunk so other contributor won't have add the same hack to their internal builds.

Evan

On Jun 4, 2013, at 9:55 AM, Quentin Colombet <qcolombet at apple.com> wrote:

> Hi Chandler,
> 
> Thanks for the feedback.
> 
> On Jun 4, 2013, at 3:44 AM, Chandler Carruth <chandlerc at google.com> wrote:
> 
>> On Mon, Jun 3, 2013 at 8:26 PM, Quentin Colombet <qcolombet at apple.com> wrote:
>> Hi Sean,
>> 
>> Thanks for the pointer!
>> 
>> It would be sufficient, but it seems to require a large amount of work for this to be done properly.
>> See r174748.
>> 
>> In my opinion, the proposed patch can be seen as the first step towards this warning. When the proper diagnostic framework land in LLVM, this could be turned into the desired warning.
>> 
>> What do you think?
>> 
>> I really would like to see this be exposed as a Clang warning if its going to go into LLVM... We have lots of user requests for it for the same reasons you outline, but the patch as it stands wouldn't address them very well.
>> 
>> I don't think we need the full generality that r174748 backs out... I would hope this could be handled more like the inline-assembly diagnostics, where essentially the frontend and the backend conspire, and the frontend specifically asks the backend to report stack frames larger than the size, and then translates that into a warning entirely in the frontend.
> I guess you are right. That I do not like however, is that every time we will need to add something similar we will have to come with something specific.
> I will see what I can do.
> 
>> 
>> However, I think what will be *really* hard about this is making the warning have a high quality and be actionable. Ideally, we would want to emit notes for each stack object contributing to the frame size, in descending order of size, with a cap on how many we emit (say the top 4, or until we are under the limit). Do you have ideas about how to get this kind of information out of LLVM and relate it to the C++ stack objects? (I ask because I've been trying to think of a way, and haven't yet succeeded... it would be awesome to have...)
> Agree.
> Nevertheless, at the moment, I do not have any ideas either on how we can do that.
>> 
>> Also, how does would this function in the face of inlining?
> The plan was straightforward: report the actual generate size, i.e., considered inlined functions as part of the original function.
> Although I am aware this is far from beginning perfect, the idea was to give a hint to the developer on where she should look. It would then be her job to find how to fix that, possibly by preventing some inlining to happen.
> 
> -Quentin
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130604/a1f2d3e7/attachment.html>