[llvm-dev] Nested instruction patterns rejected by GlobalISel when having registers in Defs

[Dominik Montada via llvm-dev]

Hi Gabriel,

I'm working on a downstream target which uses GlobalISel and we have 
many patterns with instructions that also define a system register as a 
side-effect and use them without any problem. Since CCReg is not an 
actual output of the instruction, but an implicit definition, GlobalISel 
should have no trouble with it, so I'm guessing your problem lies 
somewhere. Have you tried running the tablegen command manually and 
looked at the output there?

The command is llvm-tblgen -gen-global-isel <couple of -I flags> 
<your_target>.td --write-if-changed --warn-on-skipped-patterns

I can't tell you exactly what -I flags you'll need but if you run ninja 
in verbose mode or look at the ninja build log, you should be able to 
see what is being used.

Word of caution however: sometimes TableGen gives you a very clear error 
message indicating what is wrong, sometimes it gives you a very cryptic 
error message. And sometimes it doesn't even give you that and behave as 
if everything is a-ok while it still hasn't included your pattern. I 
have lost countless hours trying to debug TableGen patterns with 
GlobalISel and there's still a lot of stuff that GlobalISel 
unfortunately does not support yet in TableGen. So be prepared to write 
some C++ code for the unsupported cases for the moment.

Cheers,

Dominik

Am 04.06.20 um 14:34 schrieb Gabriel Hjort Åkerlund via llvm-dev:
>
> Hi,
>
> I am in the process of porting our target to GlobalISel, and have 
> encountered a problem. Nearly all instructions in our instruction set 
> make modifications to a CC register, and hence are defined as follows:
>
> let ..., Defs = [CCReg] in
>
> def shfts_a32_imm7: Instruction<(outs OurRC:$dst), ...>;
>
> What’s more, many of these instructions have patterns where the 
> instruction itself appears inside a nested tree, e.g.:
>
> def Pat<(source pattern ...),
>
>         (sext_a32 (INSERT_SUBREG (...), (shfts_a32_imm7 OurRC:$src, 
> Imm7:$imm), ...>;
>
> Now to the problem: When TableGen processes the instruction above, it 
> includes the CCRegin the Defsfield along with the registers appearing 
> in outs, thereby indicating that shfts_a32_imm7 produces two results. 
> Currently, the GlobalISel-backend in TableGen requires that nested 
> instructions appearing in the output pattern produce exactly one 
> result. Consequently, TableGen rejects many of our patterns. But in 
> reality, the instruction really only produces a single result and 
> therefore this pattern should be allowed.
>
> So I wonder, how should registers appear in Defsbe treated? Are they 
> equal to those appearing in outs, and therefore interchangeable, or is 
> it valid to disambiguate between them and therefore modify TableGen to 
> only consider outs as the result of interest when processing the patterns?
>
> *Gabriel Hjort Åkerlund*
>
>
> _______________________________________________
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200604/b06c2296/attachment.html>
-------------- 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/20200604/b06c2296/attachment.bin>