[llvm-dev] Updating RegMask inline

[vivek pandya via llvm-dev]

On Sat, May 28, 2016 at 7:29 AM, Matthias Braun <matze at braunis.de> wrote:

>
> On May 27, 2016, at 6:55 PM, vivek pandya via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>
>
> On Sat, May 28, 2016 at 12:23 AM, vivek pandya <vivekvpandya at gmail.com>
> wrote:
>
>>
>>
>> On Sat, May 28, 2016 at 12:21 AM, Mehdi Amini <mehdi.amini at apple.com>
>> wrote:
>>
>>>
>>> > On May 27, 2016, at 11:49 AM, vivek pandya <vivekvpandya at gmail.com>
>>> wrote:
>>> >
>>> > Hello Mentors,
>>> >
>>> > I have completed writing simple register mask calculator pass, an
>>> immutable pass that stores RegMasks and provides API to query them, and a
>>> target specific pass for X86 target which currently iterates through all MI
>>> in given MF and if a call instruction is found then it quires for RegMask
>>> to Immutable pass and prints which registers are clobbered and preserved as
>>> per actual register allocation for callee function.
>>> >
>>> > So now I need to update RegMask for call instruction, so as per our
>>> previous discussion on IRC if we add a method to update RegMask, Do we have
>>> to do it in target specific way? Is it possible to have RegMask at fixed
>>> position in Operands array in MI? Also provide some more details on
>>> updating cached RegMask in various other class.
>>>
>>> Add a method "setOperandMask()" in class MachineOperand, and then when
>>> you find a call you just walk all the operands till you find one which
>>> "isRegMask()" at which point you can update it.
>>>
>>> Ok.
>>
>
> Is it ok to add "setRegMaskOperand()" in class MI and looping through
> operands to find RegMask is also included in method ?
> -Vivek
>
>
> I expect your code to be the only user of such a function  so I would not
> add it to MachineInstr but keep the code local in your pass for now (you
> can add a static helper function in the .cpp file of your pass).
>
> But Operands are private to MI so It should go into MI or some other
tricks like Friend Function ?
Vivek

> - Matthias
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160528/9118084f/attachment-0001.html>