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

[Alex L]

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>