llvm dev - Jun 2015 - [LLVMdev] Replacing a Reg MachineOperand with a non-Reg MachineOperand?

I have a MachineOperand that could be something other than a Reg: mem,
global address, imm, etc...

I want to replace a reg MachineOperand with this non-reg MachineOperand.

I've tried a few different things, but it doesn't seem like there is
some
simple functionality to do this?

"RemoveOperand" and "addOperand" does not work.
There doesn't seem to be a valid "ChangeTo..." function for this.


What's the best way to do this without tearing down the instructions and
using BuildMI?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150615/e17f46ab/attachment.html>

On Mon, Jun 15, 2015 at 10:16:47PM -0400, Ryan Taylor
wrote:
> I have a MachineOperand that could be something other than a Reg: mem,
> global address, imm, etc...
> 
> I want to replace a reg MachineOperand with this non-reg MachineOperand.
> 
> I've tried a few different things, but it doesn't seem like there
is some
> simple functionality to do this?
> 
> "RemoveOperand" and "addOperand" does not work.
> There doesn't seem to be a valid "ChangeTo..." function for
this.
> 
> 
What type of operand do you want to change it to?  If there is no
"ChangeTo..." function for the new type, I think the best thing to do
would be to add a new "ChangeTo..." function to handle the new type.

-Tom
> What's the best way to do this without tearing down the instructions
and
> using BuildMI?
> 
> Thanks.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Tom,

  My current example is a global address; however, it could be any operand
in theory. The arch allows for direct mem op support for ex instructions,
so it could be any type of address or any type of imm or any type of
register.

  For example, we are using intrinsics for some instructions since LLVM
does not support them. Table gen does not allow for matching to direct mem
op because the intrinsics are calls, so registers are setup for the call
parameters. So we end up with something like:

  mov @a, r0
  abs r0, r1

In our arch, we should be able to do 'abs @a, r1'. So since the
intrinsics
won't match properly in the tblgen we're looking at doing a peephole
where
we want to replace the operand 'r0' with @a and remove the 'mov @a,
r0'
instruction, so it would look like:

  abs @a, r1

Thanks.

ps. We could add these operators to LLVM instead of using intrinsics but
that also introduces a lot of dev cost and maintenance cost and some other
technical issues, but then we could have the operators match in the tblgen.
We are looking to avoid this, we thought a simple peephole would do the
trick instead.

On Tue, Jun 16, 2015 at 9:57 AM, Tom Stellard <tom at stellard.net> wrote:
> On Mon, Jun 15, 2015 at 10:16:47PM -0400, Ryan Taylor wrote:
> > I have a MachineOperand that could be something other than a Reg: mem,
> > global address, imm, etc...
> >
> > I want to replace a reg MachineOperand with this non-reg
MachineOperand.
> >
> > I've tried a few different things, but it doesn't seem like
there is some
> > simple functionality to do this?
> >
> > "RemoveOperand" and "addOperand" does not work.
> > There doesn't seem to be a valid "ChangeTo..." function
for this.
> >
> >
>
> What type of operand do you want to change it to?  If there is no
> "ChangeTo..." function for the new type, I think the best thing
to do
> would be to add a new "ChangeTo..." function to handle the new
type.
>
> -Tom
>
> > What's the best way to do this without tearing down the
instructions and
> > using BuildMI?
> >
> > Thanks.
>
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150616/424464aa/attachment.html>