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

[Reid Kleckner]

I don't think this solves our problem, though.  We don't run lint after
every optimization pass and crash if it fails.  We do run the verifier,
though.  I'm very concerned about shaking out inalloca bugs, and optimizer
bugs are a lot easier to understand at compile time than at runtime.


On Sat, May 3, 2014 at 11:36 PM, Chandler Carruth <chandlerc at google.com>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> 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
>>
>
>
> _______________________________________________
> 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/29c9b1a7/attachment.html>