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

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

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.

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

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

In some sense, it's ConstantExpr done right: it's a Constant with some
sort of opcode, and operands.

It's rather different from ConstantExpr in the sense that it won't be
usable as constant folding API. It will only have operations which
actually make sense, it won't share an opcode space with Instructions,
it won't have the implementation quirks of ConstantExpr (like
canTrap()), and we can come up with more sane rules for what operands
are allowed for a given operation.

-Eli