[LLVMdev] Replacing a Reg MachineOperand with a non-Reg MachineOperand?

Tue Jun 16 11:15:02 PDT 2015

So I have this in the MI:

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

Then I call ChangeToGlobalAddress on ABS vreg5 to <ga:@a>. Then I erase the
MOV. Without doing anything else I get a use before def on vreg5 in SUB
vreg7, vreg5

So, then after changing ABS vreg5, I do a use iterator on MOV
->getOperand(0), which should be vreg5, and the first return of
use_iterator.getOperand() is vreg5, but when I call ChangeToGlobalAddress I
get 'not a register operand'. I'm obviously missing something here.

I'm not even sure why vreg5 is in the use list of it's supposedly been
removed the first time I called ChangeToGlobalAddress on ABS vreg5?

Thanks.

On Tue, Jun 16, 2015 at 1:50 PM, Ryan Taylor <ryta1203 at gmail.com> wrote:

> Alex,
>
>   No, it's removing it before, just like in ChangeToImmediate.
>
> void MachineOperand::ChangeToGlobalAddress(const GlobalValue *GV, int64_t
> Offset) {
>   assert((!isReg() || !isTied()) && "Cannot change a tied operand into a
> global");
>   if (isReg() && isOnRegUseList())
>     if (MachineInstr *MI = getParent())
>       if (MachineBasicBlock *MBB = MI->getParent())
>         if (MachineFunction *MF = MBB->getParent())
>           MF->getRegInfo().removeRegOperandFromUseList(this);
>   OpKind = MO_GlobalAddress;
>   setOffset(Offset);
>   Contents.OffsetedInfo.Val.GV = GV;
> }
>
>
> The problem is that I'm getting a use before def on vreg5 now further down
> the instruction list. Not sure why this is the case?
>
> Thanks.
>
>
> On Tue, Jun 16, 2015 at 1:17 PM, Alex L <arphaman at gmail.com> wrote:
>
>> 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/902ec625/attachment.html>