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

Hey Ryan,

You end with a large constant immediate offset value because the register
operand stores the register id in a union together with the offset that's
used by the global address operand.

Just add 'setOffset(0)' to your change method and that should solve your
problem.

2015-06-16 9:15 GMT-07:00 Ryan Taylor <ryta1203 at gmail.com>:
> So I have this for ChangeToGlobalAddress(const GlobalValue *GV):
>
> ...
> OpKind = MO_GlobalAddress;
> Contents.OffsetedInfo.Val.GV = GV;
>
> and then I use the function like this:
>
>
>
MI->getOperand(1).ChangeToGlobalAddress(MII->getOperand(1).getOperand.getGlobal());
>
> The operand ends up being replaced with the global; however, it's also
> adding a large constant immediate value with it.
>
> For example, instead of <ga:@a> I end up with
<ga:@a+2147483653> and
> instead of <ga:@a+100> I end up with <ga:@a+214748564>
>
> What might I be doing wrong?
>
> Thanks.
>
> On Tue, Jun 16, 2015 at 10:12 AM, Ryan Taylor <ryta1203 at gmail.com>
wrote:
>
>> 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
>>>
>>>
>>
>
> _______________________________________________
> 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/516e94cf/attachment.html>

@Alex: Thanks. setOffset(0) eliminated any previous offsets, of course, so
I added another param (int64_t Offset) and am adding that, this should
preserve the orginial offset of the GA.

Sorry, I put the above response in the wrong thread.

Also, when I try to use this new function to do the same thing on it's
uses, I get an error that vreg5 is somehow not a register?

So, the MI looks like this:

vreg5 = MOV <ga:@a>
vreg2 = ABS vreg5
...
...
vreg9 = SUB vreg7, vreg5

In this case, I want to eliminate vreg5 and replace it with <ga:@a>, the
ChangeToGlobalAddress is working for the ABS but for some reason, when I
get the uses of vreg5 it tells me it's not an register operand (vreg5 is
not), which makes sense since ChangeToGlobalAddress is calling
removeRegOperandFromUseList(this) for ABS, but it's confusing because then
why does vreg5 have any uses?



On Tue, Jun 16, 2015 at 12:36 PM, Alex L <arphaman at gmail.com> wrote:
> Hey Ryan,
>
> You end with a large constant immediate offset value because the register
> operand stores the register id in a union together with the offset
that's
> used by the global address operand.
>
> Just add 'setOffset(0)' to your change method and that should solve
your
> problem.
>
> 2015-06-16 9:15 GMT-07:00 Ryan Taylor <ryta1203 at gmail.com>:
>
>> So I have this for ChangeToGlobalAddress(const GlobalValue *GV):
>>
>> ...
>> OpKind = MO_GlobalAddress;
>> Contents.OffsetedInfo.Val.GV = GV;
>>
>> and then I use the function like this:
>>
>>
>>
MI->getOperand(1).ChangeToGlobalAddress(MII->getOperand(1).getOperand.getGlobal());
>>
>> The operand ends up being replaced with the global; however, it's
also
>> adding a large constant immediate value with it.
>>
>> For example, instead of <ga:@a> I end up with
<ga:@a+2147483653> and
>> instead of <ga:@a+100> I end up with <ga:@a+214748564>
>>
>> What might I be doing wrong?
>>
>> Thanks.
>>
>> On Tue, Jun 16, 2015 at 10:12 AM, Ryan Taylor <ryta1203 at
gmail.com> wrote:
>>
>>> 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
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> 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/0c025d92/attachment.html>

I'm not sure I understand what your problem is, but are you calling the
removeRegOperandFromUseList on the machine operand after changing it to GA?
You have to call removeRegOperandFromUseList before changing the operand's
type, as it expects a register operand.

2015-06-16 10:05 GMT-07:00 Ryan Taylor <ryta1203 at gmail.com>:
> @Alex: Thanks. setOffset(0) eliminated any previous offsets, of course, so
> I added another param (int64_t Offset) and am adding that, this should
> preserve the orginial offset of the GA.
>
> Sorry, I put the above response in the wrong thread.
>
> Also, when I try to use this new function to do the same thing on it's
> uses, I get an error that vreg5 is somehow not a register?
>
> So, the MI looks like this:
>
> vreg5 = MOV <ga:@a>
> vreg2 = ABS vreg5
> ...
> ...
> vreg9 = SUB vreg7, vreg5
>
> In this case, I want to eliminate vreg5 and replace it with <ga:@a>,
the
> ChangeToGlobalAddress is working for the ABS but for some reason, when I
> get the uses of vreg5 it tells me it's not an register operand (vreg5
is
> not), which makes sense since ChangeToGlobalAddress is calling
> removeRegOperandFromUseList(this) for ABS, but it's confusing because
then
> why does vreg5 have any uses?
>
>
>
> On Tue, Jun 16, 2015 at 12:36 PM, Alex L <arphaman at gmail.com>
wrote:
>
>> Hey Ryan,
>>
>> You end with a large constant immediate offset value because the
register
>> operand stores the register id in a union together with the offset
that's
>> used by the global address operand.
>>
>> Just add 'setOffset(0)' to your change method and that should
solve your
>> problem.
>>
>> 2015-06-16 9:15 GMT-07:00 Ryan Taylor <ryta1203 at gmail.com>:
>>
>>> So I have this for ChangeToGlobalAddress(const GlobalValue *GV):
>>>
>>> ...
>>> OpKind = MO_GlobalAddress;
>>> Contents.OffsetedInfo.Val.GV = GV;
>>>
>>> and then I use the function like this:
>>>
>>>
>>>
MI->getOperand(1).ChangeToGlobalAddress(MII->getOperand(1).getOperand.getGlobal());
>>>
>>> The operand ends up being replaced with the global; however,
it's also
>>> adding a large constant immediate value with it.
>>>
>>> For example, instead of <ga:@a> I end up with
<ga:@a+2147483653> and
>>> instead of <ga:@a+100> I end up with <ga:@a+214748564>
>>>
>>> What might I be doing wrong?
>>>
>>> Thanks.
>>>
>>> On Tue, Jun 16, 2015 at 10:12 AM, Ryan Taylor <ryta1203 at
gmail.com>
>>> wrote:
>>>
>>>> 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
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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/71258aa4/attachment.html>