llvm dev - Jul 2013 - [LLVMdev] Clarification on alloca semantics

According to the language reference:

*The ‘alloca‘ instruction allocates memory on the stack frame of the
currently executing function, to be automatically released when this
function returns to its caller. The object is always allocated in the
generic address space (address space zero).*


The last sentence specifies where the memory is allocated, but it's not
clear precisely what "allocated in the generic address space" means. 
For
architectures with a segmented memory layout, allocating "in" the
generic
address space may not make sense.  Instead, you allocate in a specific
address space, and create a "generic" pointer to that allocation.  Is
this
a legal interpretation of the language reference?

If so, I would like to make the text in the language reference more
explicit that this is allowed.  If not, I would like to petition to make
this legal.  Something along the lines of:

*The object is allocated in a target-defined memory space and the returned
pointer is always in the generic address space (address space zero).*

-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130712/694ec2d1/attachment.html>

Is there any reason why it is saying "generic address space (address space
zero)" and not just "address space zero"?

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130712/2444b767/attachment.html>

Good question.  As far as I know, there is no specification that dictates
address space 0 is a "generic" address space for the target.


On Fri, Jul 12, 2013 at 4:38 PM, Sean Silva <silvas at purdue.edu> wrote:
> Is there any reason why it is saying "generic address space (address
space
> zero)" and not just "address space zero"?
>
> -- Sean Silva
>


-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130712/2519b5fd/attachment.html>