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

[Philip Reames]

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 
> <mailto:clattner at apple.com>> wrote:
>
>
>     On May 2, 2014, at 3:28 PM, Reid Kleckner <rnk at google.com
>     <mailto: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 <mailto: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
> 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/2da99e81/attachment.html>