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

Chandler Carruth chandlerc at google.com
Tue Jun 4 03:44:56 PDT 2013


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.

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...)

Also, how does would this function in the face of inlining?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130604/e849a4b3/attachment.html>


More information about the llvm-commits mailing list