[llvm-dev] CloneMachineInstr and register ties
Harald van Dijk via llvm-dev
llvm-dev at lists.llvm.org
Tue Dec 18 05:49:38 PST 2018
On 06/12/2018 16:11, Harald van Dijk via llvm-dev wrote:
> Hi,
>
> Working on a new pass for a project based on LLVM 4.0.1 I tried to clone
> a machine instruction using MachineFunction::CloneMachineInstr. Its
> documentation reads
>
>> /// CloneMachineInstr - Create a new MachineInstr which is a copy of the
>> /// 'Orig' instruction, identical in all ways except the instruction
>> /// has no parent, prev, or next.
>> ///
>> /// See also TargetInstrInfo::duplicate() for target-specific fixes to
>> cloned
>> /// instructions.
>
> which has since been changed to
>
>> /// Create a new MachineInstr which is a copy of \p Orig, identical in
>> all
>> /// ways except the instruction has no parent, prev, or next. Bundling
>> flags
>> /// are reset.
>> ///
>> /// Note: Clones a single instruction, not whole instruction bundles.
>> /// Does not perform target specific adjustments; consider using
>> /// TargetInstrInfo::duplicate() instead.
>
> Based on either, I expected register ties to remain intact on the clone,
> but they are cleared. I can see how that happens (MachineInstr's
> constructor copies all machine operands one by one; when adding existing
> machine operands using MachineInstr::addOperand, ties are supposed to be
> cleared), but the documentation suggests to me the ties should be
> restored after all operands have been added.
>
> Or is the new comment about bundling flags meant to cover register ties
> too? I think that's only about machine instruction bundles, but maybe
> I'm not understanding it right.
>
> I can patch up register ties afterwards if necessary, but I'd like to
> know if this is a bug or not, because it affects whether I should do the
> patching up in my own pass or in the LLVM code, and whether I should
> report this as a bug.
Because of the lack of response, I have reported it as a bug[1], but for
now will treat CloneMachineInstr as if it is supposed to behave this
way, and work around it in my own pass.
[1]: https://bugs.llvm.org/show_bug.cgi?id=40079
> Cheers,
> Harald van Dijk
More information about the llvm-dev
mailing list