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

[Quentin Colombet]

Hi Chandler, hi Sean,

I wanted to double check with you what is your opinion about the proposed patch.

Sean, it seems you agree that this gets in, but additionally we need to make a plan for the future.

Chandler, you did not want it in until it gets a warning in clang. How Evan’s comment affected your thought?

If you both agree, I can commit this patch and start a discussion on llvm-dev regarding how we can support backend warnings into clang.

What do you think?

Thanks for your time,

-Quentin

On Jun 4, 2013, at 1:22 PM, Quentin Colombet <qcolombet at apple.com> wrote:

> 
> On Jun 4, 2013, at 12:22 PM, Sean Silva <silvas at purdue.edu> 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 think it is a reasonable first step, but as Evan points out, it is really more of a hack (dumping to errs() :| )than a proper solution.
> I agree that this is a hack (in fact it is what is actually done for error reporting when no diagnostic mechanism is available). But as Evan points out too, we thought it would be useful to have it into trunk to avoid the same hack for being implemented by other contributors in their internal builds.
> 
>> What are the next steps to evolving this feature into a proper solution, and are you guys planning on taking those steps?
> To me, the next step would be to make llvm and clang have a nicer interface to pass diagnostics.
> However, I do not know this part of the compiler enough, at the moment, to be able to describe the next steps.
> 
> The general design should be discussed on the llvm dev mailing list, then we can plan who will make what.
> 
> Nevertheless, we may not be able to allocate resource on that in the near future. Again, we can only speculate until we have a plan!
>  
>> I don't think we want to just introduce a hack and leave it as such.
>> 
>> -- Sean Silva
> -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/20130605/829fd151/attachment.html>