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

I am looking for a way to allow ConstantExpr to express target specific
operations, which will be used in global initializers.

The recommended way to extend LLVM IR is using intrinsic functions. But this
does not work for ConstantExpr, which the global initializer uses.

Should we make ConstantExpr to support some kind of side-effect free intrinsic
function calls? If we want to work on such a patch, what are the things we
should look out for?

http://llvm.org/bugs/show_bug.cgi?id=10368 seems also express this desire.

Thanks.

Yuan




-----------------------------------------------------------------------------------
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/b692ba71/attachment.html>

On Dec 17, 2012, at 11:26 AM, Yuan Lin <yulin at nvidia.com> wrote:
> I am looking for a way to allow ConstantExpr to express target specific
operations, which will be used in global initializers.
>  
> The recommended way to extend LLVM IR is using intrinsic functions. But
this does not work for ConstantExpr, which the global initializer uses.
>  
> Should we make ConstantExpr to support some kind of side-effect free
intrinsic function calls? If we want to work on such a patch, what are the
things we should look out for?
>  
> http://llvm.org/bugs/show_bug.cgi?id=10368 seems also express this desire.
>  
That PR is still accurate as to the direction I think ConstantExprs should go. 
What specifically does this target-specific constant need to look like?

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121217/88dcb0ea/attachment.html>

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.

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


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


On Dec 17, 2012, at 11:26 AM, Yuan Lin <yulin at nvidia.com<mailto:yulin
at nvidia.com>> wrote:


I am looking for a way to allow ConstantExpr to express target specific
operations, which will be used in global initializers.

The recommended way to extend LLVM IR is using intrinsic functions. But this
does not work for ConstantExpr, which the global initializer uses.

Should we make ConstantExpr to support some kind of side-effect free intrinsic
function calls? If we want to work on such a patch, what are the things we
should look out for?

http://llvm.org/bugs/show_bug.cgi?id=10368 seems also express this desire.


That PR is still accurate as to the direction I think ConstantExprs should go. 
What specifically does this target-specific constant need to look like?

-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/09c8163d/attachment.html>