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

[Chandler Carruth]

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> wrote:

>
> On May 2, 2014, at 3:28 PM, Reid Kleckner <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
> 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/20140503/748af4cf/attachment.html>