[cfe-dev] [LLVMdev] [pocl-devel] SPIR provisional specification is now available in the Khronos website

[James Molloy]

> After thinking about this more, I’m not sure if this is applicable to
SPIR itself. For you to have a constant GEP expression, you have to know
the pointer size in order to correctly generate the expression. Since the
pointer size itself is not known, I don’t yet see how you can generate a
constant expression that is valid SPIR.

GEP is defined relative to (indepenently of) pointer size.

On 1 October 2012 17:36, Villmow, Micah <Micah.Villmow at amd.com> wrote:

>  Maybe it would be easier to provide a bitcode example of this problem.***
> *
>
> ** **
>
> After thinking about this more, I’m not sure if this is applicable to SPIR
> itself. For you to have a constant GEP expression, you have to know the
> pointer size in order to correctly generate the expression. Since the
> pointer size itself is not known, I don’t yet see how you can generate a
> constant expression that is valid SPIR.****
>
> ** **
>
> Micah****
>
> ** **
>
> *From:* mankeyrabbit at gmail.com [mailto:mankeyrabbit at gmail.com] *On Behalf
> Of *James Molloy
> *Sent:* Saturday, September 29, 2012 5:30 AM
> *To:* Owen Anderson
> *Cc:* Villmow, Micah; llvmdev at cs.uiuc.edu;
> pocl-devel at lists.sourceforge.net; cfe-dev at cs.uiuc.edu
> *Subject:* Re: [LLVMdev] [pocl-devel] [cfe-dev] SPIR provisional
> specification is now available in the Khronos website****
>
> ** **
>
> Yes, it would.****
>
> ** **
>
> But I was concerned Micah was just going to write it off as an
> implementation detail, so I felt that I should offer a "less correct but
> less work" option for him to consider.****
>
> ** **
>
> Cheers,****
>
> ** **
>
> James****
>
> On 29 September 2012 03:16, Owen Anderson <resistor at mac.com> wrote:****
>
> ** **
>
> On Sep 28, 2012, at 9:45 AM, James Molloy <james at jamesmolloy.co.uk> wrote:
> ****
>
>
>
> ****
>
> You can easily simplify this problem with a restriction in SPIR: disallow
> ConstantExpr casts - no ptrtoint constant expression. Because
> GlobalVariables have pointer type, if you disallow converting their type to
> non-pointer type in a constantexpr, the number of constantexpr subclasses
> you have to deal with is drastically reduced (to essentially just BitCast
> and GEP).****
>
> ** **
>
> Wouldn't an easier solution just be not to represent them as constants in
> the first place?  For instance, you could have a built-in function to get
> the address of local N, where N is taken as a parameter.  You can call the
> builtins at the beginning of the kernel, and then proceed to use them as
> you wish without having to worry about reversing a constant folding later.
>  Plus, if a given vendor's backend *wants* the address to get constant
> folded, it's easy to do replaceAllUsesWith of the call with a global, and
> run an appropriate constant folding pass.****
>
> ** **
>
> --Owen****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121001/e9b79080/attachment.html>