llvm dev - Dec 2012 - [LLVMdev] target specific ways to extend ConstantExpr

We cannot use bitcast because bitcast is a value preserving operation, but the
address space conversion operation we have is a bit-changing operation.

Where will the bulk of work be? Can we make a ConstantExpr which has a new
Opcode (or reuse call) and a list of operands? The first operand is a string.

From: Chris Lattner [mailto:clattner at apple.com]
Sent: Monday, December 17, 2012 4:39 PM
To: Yuan Lin
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] target specific ways to extend ConstantExpr


On Dec 17, 2012, at 4:23 PM, Yuan Lin <yulin at nvidia.com<mailto:yulin at
nvidia.com>> wrote:


The particular case we are looking at is converting a pointer from one address
space to another address space. There is one operand and one output, both are
the same pointer type, except for their address space. The pointers are of the
same size. The operation is a bit-changing operation.
 We are using intrinsic functions for the instructions. We need a solution for
the ConstantExpr.

Sounds like a bitcast to me.  Is there a reason the bitcast constexpr isn't
working for you?


Instead of adding one target specific expression, it would be better to have a
more generic scheme in LLVM.

I agree!  However, fixing this is also a lot of work.

-Chris


-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information.  Any unauthorized review, use, disclosure or
distribution
is prohibited.  If you are not the intended recipient, please contact the sender
by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121217/85af0f7c/attachment.html>

On Mon, Dec 17, 2012 at 5:10 PM, Yuan Lin <yulin at nvidia.com>
wrote:
> We cannot use bitcast because bitcast is a value preserving operation, but
> the address space conversion operation we have is a bit-changing operation.
>
>
>
> Where will the bulk of work be? Can we make a ConstantExpr which has a new
> Opcode (or reuse call) and a list of operands? The first operand is a
> string.
I would suggest adding a new subclass to Constant; that's closer to
the direction we want to be moving in.  It'll look somewhat similar to
ConstantExpr, but you don't want to mess with the opcodes ConstantExpr
uses, and messing with the existing ConstantExpr code to allow
MDStrings as operands would probably be harder than writing a class
from scratch.

-Eli

That's an interesting idea. What are the essential differences between the
new subclass and ConstantExpr? Will it end up like ConstantExpr? Or you want it
to be ConstantExpr 'done right'?

Thanks.

Yuan


-----Original Message-----
From: Eli Friedman [mailto:eli.friedman at gmail.com] 
Sent: Monday, December 17, 2012 5:40 PM
To: Yuan Lin
Cc: Chris Lattner; llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] target specific ways to extend ConstantExpr

On Mon, Dec 17, 2012 at 5:10 PM, Yuan Lin <yulin at nvidia.com>
wrote:
> We cannot use bitcast because bitcast is a value preserving operation, 
> but the address space conversion operation we have is a bit-changing
operation.
>
>
>
> Where will the bulk of work be? Can we make a ConstantExpr which has a 
> new Opcode (or reuse call) and a list of operands? The first operand 
> is a string.
I would suggest adding a new subclass to Constant; that's closer to the
direction we want to be moving in.  It'll look somewhat similar to
ConstantExpr, but you don't want to mess with the opcodes ConstantExpr uses,
and messing with the existing ConstantExpr code to allow MDStrings as operands
would probably be harder than writing a class from scratch.

-Eli
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information.  Any unauthorized review, use, disclosure or
distribution
is prohibited.  If you are not the intended recipient, please contact the sender
by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------