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

[David Majnemer]

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> 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 listllvm-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/dea8d53b/attachment.html>