Dominik Montada via llvm-dev
2020-Dec-01 12:27 UTC
[llvm-dev] Tie output operand to subregister of input operand
Hi Quentin, thanks for the response. Your suggested work-around is exactly what we're using for the moment. It's a shame that we "lose" the upper bits this way, but guess it's the best we can do for now. Would be nice if this is supported at some point in the future :) Cheers, Dominik Am 01.12.20 um 00:49 schrieb Quentin Colombet:> Hi Dominik, > > >> On Nov 27, 2020, at 5:24 AM, Dominik Montada via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi, >> >> I have an instruction that takes a 64-bit register as input and uses the lower 32-bit subregister as output. I am struggling to define the constraint in TableGen to make this work however. >> >> Originally I had the following constraint: >> >> let Constraint = "$dst = $src" in >> def Foo : Instruction<..., (out GPR32:$dst), (ins GPR64:$src), ...>; >> >> This however causes the following code to be produced: >> >> %1:GPR32 = COPY %0:GPR64 >> %1:GPR32 = Foo %1:GPR32(tied-def 0) >> >> Which causes an error, because the input to Foo must be a GPR64, not a GPR32. >> >> I stumbled across complex operands, i.e. operands with suboperands: >> >> def subregpair : Operand<i64> { >> let MIOperandInfo = (ops GPR32:$lo, GPR32:$hi); >> } >> >> let Constraint = "$dst = $src.lo" in >> def Foo : Instruction<..., (out GPR32:$dst), (ins subregpair:$src), ...>; >> >> However I'm not sure whether I'm using this correctly and if this is even the intended use-case for it, because I now get an error that Foo expects 2 operands, not 1. > I don’t think this is the intended use-case, but what you see is expected. IIRC the complex operands are just a convenient way to setup several operands that are logically connected, but they are still different operands. This is what is used for X86 addressing mode for instance. At the td level, this is just one complex operand (X86Mem) but when the instruction is built, every individual operand needs to be set (see addFullAddress). > >> Is this even doable in TableGen or will I need to manually fix up the registers somehow? > I don’t think this is doable in TableGen, but take it with a grain of salt, I am no TableGen expert! > > If you're okay with losing the upper part of the register (for register allocation purposes), you could model that as a regular 64-bit tied operand followed by an extract_subreg. > > Cheers, > -Quentin > >> Cheers, >> >> Dominik >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- ---------------------------------------------------------------------- Dominik Montada Email: dominik.montada at hightec-rt.com HighTec EDV-Systeme GmbH Phone: +49 681 92613 19 Europaallee 19 Fax: +49-681-92613-26 D-66113 Saarbrücken WWW: http://www.hightec-rt.com Managing Director: Vera Strothmann Register Court: Saarbrücken, HRB 10445, VAT ID: DE 138344222 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. --- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6822 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201201/b7ca05ab/attachment.bin>