[llvm-commits] [llvm] r151710 - /llvm/trunk/docs/LangRef.html

[Nick Lewycky]

Eli Friedman wrote:
> On Wed, Feb 29, 2012 at 12:26 AM, Nick Lewycky<nicholas at mxc.ca>  wrote:
>> Author: nicholas
>> Date: Wed Feb 29 02:26:44 2012
>> New Revision: 151710
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=151710&view=rev
>> Log:
>> Where the alloca'd space actually lives in ram is undefined, and attempting to
>> pin it down is undefined behaviour.
>>
>> Modified:
>>     llvm/trunk/docs/LangRef.html
>>
>> Modified: llvm/trunk/docs/LangRef.html
>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/LangRef.html?rev=151710&r1=151709&r2=151710&view=diff
>> ==============================================================================
>> --- llvm/trunk/docs/LangRef.html (original)
>> +++ llvm/trunk/docs/LangRef.html Wed Feb 29 02:26:44 2012
>> @@ -4859,7 +4859,12 @@
>>     variables that must have an address available.  When the function returns
>>     (either with the<tt><a href="#i_ret">ret</a></tt>
>>     or<tt><a href="#i_resume">resume</a></tt>  instructions), the memory is
>> -   reclaimed.  Allocating zero bytes is legal, but the result is undefined.</p>
>> +   reclaimed.  Allocating zero bytes is legal, but the result is undefined.
>> +   The order in which memory is allocated (ie., which way the stack grows) is
>> +   not specified, and relational comparisons involving '<tt>alloca</tt>'s are
>> +   undefined.</p>
>
> This is really aggressive.  In fact, I think it's actually more
> aggressive than the C standard actually allows, given that we
> implement local variables with alloca.  Specifically, C allows casting
> a pointer to an integer, and all operations on that integer are
> well-defined.

I agree, but IIUC casting pointer to integer doesn't provide any meaning 
to that integer, except for what you get when you cast it back to 
pointer. It does mean that %ptr1 icmp %ptr2 is not the same as 
ptrtoint(%ptr1) icmp ptrtoint(%ptr2), but that's how I understand the rules.

I didn't add this rule, this was derived from how LLVM was already 
treating alloca's. If you can demonstrate that this can cause C code to 
miscompile or that we otherwise just don't want to do it, I'll be happy 
to help be part of the fix!

Nick