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

[Ryan Taylor]

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