[PATCH] Roundtrip the inalloca bit on allocas through bitcode
rnk at google.com
Mon Jul 14 18:02:07 PDT 2014
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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits