thr3ads.net - llvm dev - [llvm-dev] Nested instruction patterns rejected by GlobalISel when having registers in Defs [Jun 2020]

If this information is useful, please help other people find it:
Share via:

Gabriel Hjort Åkerlund via llvm-dev

2020-Jun-04 13:06 UTC

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

Hi Dominik,

 

Thanks for your reply.

 

In my case, the Defs is the cause of the problem. Or rather, it is part of
the problem, because when I remove it from the instruction TableGen gives me
a different error message which concerns a part which is deeper into the
pattern tree, so at least it is able to proceed beyond that part of the
pattern. I have also stepped TableGen inside gdb and verified that having
Defs causes GlobalISel to include CCReg in the Types field of the
TreePatternNode corresponding to the instruction, which is what GlobalISel
looks at to subsequently reject the pattern on basis that the instruction
produces multiple results.

 

But from your comment, I take it that the Defs field should never be
considered actual output, is that correct? If so, I find it strange that
CodeGenDAGPatterns, which parses the patterns, takes the CCReg into
consideration as additional results. I am tempted to modify that part of the
code, but maybe Im missing some invariant thats not immediately evident


 

Cheers,

Gabriel

 

From: Dominik Montada <dominik.montada at hightec-rt.com> 
Sent: den 4 juni 2020 14:51
To: llvm-dev at lists.llvm.org
Cc: Gabriel Hjort Åkerlund <gabriel.hjort.akerlund at ericsson.com>
Subject: Re: [llvm-dev] Nested instruction patterns rejected by GlobalISel
when having registers in Defs

 

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), ...>;

 

Whats 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 CCReg in the Defs field 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 Defs be 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 <mailto:llvm-dev at lists.llvm.org> 
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://protect2.fireeye.com/v1/url?k=52e18446-0c413e28-52e1c4dd-86b1886cfa
64-f424e731a80348bd&q=1&e=238953c8-f0ec-4510-8c97-620bfb03d5be&u=https%3A%2F
%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev> 

-- 
----------------------------------------------------------------------
Dominik Montada                   Email: dominik.montada at hightec-rt.com
<mailto: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
<https://protect2.fireeye.com/v1/url?k=a0228059-fe823a37-a022c0c2-86b1886cfa
64-48b7aa6978940111&q=1&e=238953c8-f0ec-4510-8c97-620bfb03d5be&u=http%3A%2F%
2Fwww.hightec-rt.com%2F> 
 
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/3e700747/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6320 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200604/3e700747/attachment.bin>

Dominik Montada via llvm-dev

2020-Jun-05 07:48 UTC

head link

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

Hi Gabriel,

Your comment made me take a look at our instruction definitions and 
patterns in a little bit more detail. And while we do use nested 
patterns with INSERT_SUBREG, apparently none of those patterns use 
instructions with implicit-defs. Sorry for misleading you there by a 
wrong assumption on my part.

However, I still find it strange that TableGen should reject such a 
pattern. I'm really not sure if this is simply an overlooked use-case or 
if there is some real reasoning behind this logic. If it were an actual 
output register I could understand it, but since this is an implicit one 
it should not impact the pattern in my opinion.

Sorry for not being able to help out with the actual problem after all!

Cheers,

Dominik

Am 04.06.20 um 15:06 schrieb Gabriel Hjort Åkerlund:>
> Hi Dominik,
>
> Thanks for your reply.
>
> In my case, the Defsis the cause of the problem. Or rather, it is part 
> of the problem, because when I remove it from the instruction TableGen 
> gives me a different error message which concerns a part which is 
> deeper into the pattern tree, so at least it is able to proceed beyond 
> that part of the pattern. I have also stepped TableGen inside gdband 
> verified that having Defs causes GlobalISel to include CCRegin the 
> Typesfield of the TreePatternNodecorresponding to the instruction, 
> which is what GlobalISel looks at to subsequently reject the pattern 
> on basis that the instruction produces multiple results.
>
> But from your comment, I take it that the Defsfield should never be 
> considered actual output, is that correct? If so, I find it strange 
> that CodeGenDAGPatterns, which parses the patterns, takes the CCReg 
> into consideration as additional results. I am tempted to modify that 
> part of the code, but maybe I’m missing some invariant that’s not 
> immediately evident…
>
> Cheers,
>
> Gabriel
>
> *From:*Dominik Montada <dominik.montada at hightec-rt.com>
> *Sent:* den 4 juni 2020 14:51
> *To:* llvm-dev at lists.llvm.org
> *Cc:* Gabriel Hjort Åkerlund <gabriel.hjort.akerlund at ericsson.com>
> *Subject:* Re: [llvm-dev] Nested instruction patterns rejected by 
> GlobalISel when having registers in Defs
>
> 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  <mailto:llvm-dev at lists.llvm.org>
>
>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev 
<https://protect2.fireeye.com/v1/url?k=52e18446-0c413e28-52e1c4dd-86b1886cfa64-f424e731a80348bd&q=1&e=238953c8-f0ec-4510-8c97-620bfb03d5be&u=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev>
>
> -- 
> ----------------------------------------------------------------------
> Dominik Montada                   Email:dominik.montada at hightec-rt.com 
<mailto: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 
<https://protect2.fireeye.com/v1/url?k=a0228059-fe823a37-a022c0c2-86b1886cfa64-48b7aa6978940111&q=1&e=238953c8-f0ec-4510-8c97-620bfb03d5be&u=http%3A%2F%2Fwww.hightec-rt.com%2F>
> 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.
> ---
-- 
----------------------------------------------------------------------
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/20200605/145c6f3e/attachment-0001.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/20200605/145c6f3e/attachment-0001.bin>

Quentin Colombet via llvm-dev

2020-Jun-05 18:02 UTC

head link

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

+ Daniel who knows the most about the table gen importer
> On Jun 5, 2020, at 12:48 AM, Dominik Montada via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hi Gabriel,
> 
> Your comment made me take a look at our instruction definitions and
patterns in a little bit more detail. And while we do use nested patterns with
INSERT_SUBREG, apparently none of those patterns use instructions with
implicit-defs. Sorry for misleading you there by a wrong assumption on my part.
> 
> However, I still find it strange that TableGen should reject such a
pattern. I'm really not sure if this is simply an overlooked use-case or if
there is some real reasoning behind this logic. If it were an actual output
register I could understand it, but since this is an implicit one it should not
impact the pattern in my opinion.
> 
> Sorry for not being able to help out with the actual problem after all!
> 
> Cheers,
> 
> Dominik
> 
> Am 04.06.20 um 15:06 schrieb Gabriel Hjort Åkerlund:
>> Hi Dominik,
>>  
>> Thanks for your reply.
>>  
>> In my case, the Defs is the cause of the problem. Or rather, it is part
of the problem, because when I remove it from the instruction TableGen gives me
a different error message which concerns a part which is deeper into the pattern
tree, so at least it is able to proceed beyond that part of the pattern. I have
also stepped TableGen inside gdb and verified that having Defs causes GlobalISel
to include CCReg in the Types field of the TreePatternNode corresponding to the
instruction, which is what GlobalISel looks at to subsequently reject the
pattern on basis that the instruction produces multiple results.
>>  
>> But from your comment, I take it that the Defs field should never be
considered actual output, is that correct? If so, I find it strange that
CodeGenDAGPatterns, which parses the patterns, takes the CCReg into
consideration as additional results. I am tempted to modify that part of the
code, but maybe I’m missing some invariant that’s not immediately evident…
>>  
>> Cheers,
>> Gabriel
>>  
>> From: Dominik Montada <dominik.montada at hightec-rt.com>
<mailto:dominik.montada at hightec-rt.com>
>> Sent: den 4 juni 2020 14:51
>> To: llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>> Cc: Gabriel Hjort Åkerlund <gabriel.hjort.akerlund at
ericsson.com> <mailto:gabriel.hjort.akerlund at ericsson.com>
>> Subject: Re: [llvm-dev] Nested instruction patterns rejected by
GlobalISel when having registers in Defs
>>  
>> 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 CCReg in the Defs field 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 Defs be 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 <mailto:llvm-dev at lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://protect2.fireeye.com/v1/url?k=52e18446-0c413e28-52e1c4dd-86b1886cfa64-f424e731a80348bd&q=1&e=238953c8-f0ec-4510-8c97-620bfb03d5be&u=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev>
>> -- 
>> ----------------------------------------------------------------------
>> Dominik Montada                   Email: dominik.montada at
hightec-rt.com <mailto: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
<https://protect2.fireeye.com/v1/url?k=a0228059-fe823a37-a022c0c2-86b1886cfa64-48b7aa6978940111&q=1&e=238953c8-f0ec-4510-8c97-620bfb03d5be&u=http%3A%2F%2Fwww.hightec-rt.com%2F>
>>  
>> 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.
>> --- 
> -- 
> ----------------------------------------------------------------------
> Dominik Montada                   Email: dominik.montada at hightec-rt.com
<mailto: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
<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.
> --- 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200605/cfb5ba64/attachment-0001.html>

llvm dev - Jun 2020 - Nested instruction patterns rejected by GlobalISel when having registers in Defs

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

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

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