[PATCH] IR: Check inalloca call argument originating from parameter

[Philip Reames]

Good to know, thanks.

My comment wasn't specific to the patch in question.  I was trying to 
make a general point.  Sorry if my wording didn't convey that.

Philip

On 05/05/2014 10:07 AM, David Majnemer wrote:
> Philip,
>
> The patch submitted for review has already been updated to use Lint 
> instead of Verifier.
>
> -- 
> David Majnemer
>
> On Monday, May 5, 2014, Philip Reames <listmail at philipreames.com 
> <mailto:listmail at philipreames.com>> wrote:
>
>     Speaking as someone with a language frontend which fairly
>     frequently generates nonsensical code you'd never see out of
>     Clang, I *strongly* agree that this functionality should not be in
>     the Verifier.  :)
>
>     Philip
>
>     On 05/03/2014 11:36 PM, Chandler Carruth wrote:
>>     Heh. Was actua0lly looking at this in my post-commit review
>>     queue, and had the same comment. I think most of the inalloca
>>     stuff is *much* better fitting as a lint check than verifier.
>>
>>
>>     On Sat, May 3, 2014 at 10:55 PM, Chris Lattner
>>     <clattner at apple.com
>>     <javascript:_e(%7B%7D,'cvml','clattner at apple.com');>> wrote:
>>
>>
>>         On May 2, 2014, at 3:28 PM, Reid Kleckner <rnk at google.com
>>         <javascript:_e(%7B%7D,'cvml','rnk at google.com');>> wrote:
>>
>>         > So, we don't generally fail verification because somebody
>>         gave us well-formed but nonsensical IR.
>>
>>         Right.
>>
>>         > I kind of compromised on the last verifier change because I
>>         think it will save us lots of time, and we can revert it if
>>         somebody objects.  Consider the FAQ about calling convention
>>         mismatches:
>>         >
>>         >
>>         http://llvm.org/docs/FAQ.html#why-does-instcombine-simplifycfg-turn-a-call-to-a-function-with-a-mismatched-calling-convention-into-unreachable-why-not-make-the-verifier-reject-it
>>         >
>>         > It's not clear to me that this new check will find lots of
>>         optimizer bugs for us, but I could be proven wrong, and yes,
>>         it might take more time to figure it out without a verifier
>>         check.  Anyway, I think we need a second opinion to keep
>>         going in this direction, so I added Nick.
>>
>>         We really really should not put this kind of check into the
>>         verifier.  The compiler needs to be able to compile
>>         nonsensical but structurally valid code, because it may be
>>         dynamically dead, and it may be introduced by other
>>         transformations.
>>
>>         Not all hope is lost though, this is a great thing to add to
>>         llvm/lib/Analysis/Lint.cpp
>>
>>         -Chris
>>         _______________________________________________
>>         llvm-commits mailing list
>>         llvm-commits at cs.uiuc.edu
>>         <javascript:_e(%7B%7D,'cvml','llvm-commits at cs.uiuc.edu');>
>>         http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>>
>>
>>
>>     _______________________________________________
>>     llvm-commits mailing list
>>     llvm-commits at cs.uiuc.edu  <javascript:_e(%7B%7D,'cvml','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/20140505/1c9d5390/attachment.html>