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

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/llvm-dev/attachments/20120928/15ac01c4/attachment.html>

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/llvm-dev/attachments/20120929/3a48e815/attachment.html>

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<mailto:resistor at mac.com>> wrote:

On Sep 28, 2012, at 9:45 AM, James Molloy <james at
jamesmolloy.co.uk<mailto: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/llvm-dev/attachments/20121001/70ecb498/attachment.html>