[PATCH] Roundtrip the inalloca bit on allocas through bitcode

[Reid Kleckner]

On Thu, May 29, 2014 at 3:56 PM, Nick Lewycky <nlewycky at google.com> wrote:

> On 29 May 2014 13:33, Reid Kleckner <rnk at google.com> wrote:
>
>> On Thu, May 29, 2014 at 11:31 AM, Nick Lewycky <nicholas at mxc.ca> wrote:
>>
>>> Reid Kleckner wrote:
>>>
>>>> Hi nicholas, nlewycky,
>>>>
>>>> This was an oversight in the original support.  As it is, I stuffed this
>>>> bit into the alignment.  The alignment is stored in log2 form, so it
>>>> doesn't need more than 6 bits.
>>>>
>>>
>>> How was alloca encoded in the 3.4 release? What would it someone need to
>>> have in their 3.4 .bc file to cause it to be read as inalloca in 3.5?
>>> "align 18446744073709551616"?
>>
>>
>> I think using alignment of 9223372036854775808 (2**63) will be read in as
>> 'inalloca' with this patch, because it's encoded as log2(alignment)+1, and
>> reconstituted with (1<<align)>>1.  Do you want to raise the bar for the
>> maximum supported alignment?
>>
>
> Oh I'm quite happy with lowering the bar. 4MB should be too much stack
> alignment for everybody. Half the address spaces is right out. I just want
> to know the number in advance so I'm armed and ready when somebody
> complains.
>
> To be polite, if we do want to limit it, we should document the limit and
> make the verifier check it. Anybody who actually had this in their bitcode
> will discover that it doesn't work in newer llvm's.
>

I just discovered Value::MaximumAlignment when I tried to parse a .ll with
a large alignment.  Sounds like we should document it and put in some
verifier checks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140714/3c2aa144/attachment.html>