| Message ID | mptv98o3nrx.fsf@arm.com |
|---|---|
| State | New |
| Headers | show |
| Series | Better const_vector printing | expand |
On April 14, 2021 5:10:26 PM GMT+02:00, Richard Sandiford via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: >Looking at PR99929 showed that we weren't dumping enough information >about variable-length CONST_VECTORs. Something like: > > (const_vector:VNx4SI [(const_int 1) (const_int 0)]) > >could be either: > >(a) 1, 0, 1, 0, repeating >(b) 1 followed by all zeros > >This patch adds more information to the dumps. There are four cases: > >(a) above: > > (const_vector:VNx4SI repeat [ > (const_int 1) > (const_int 0) > ]) > >(b) above: > > (const_vector:VNx4SI [ > (const_int 1) > repeat [ > (const_int 0) > ] > ]) > >a single stepped sequence: > > (const_vector:VNx4SI [ > (const_int 0) > stepped [ > (const_int 1) > (const_int 2) > ] > ]) > >interleaved stepped sequences: > > (const_vector:VNx4SI [ > (const_int 0) > (const_int 40) > stepped (interleave 2) [ > (const_int 1) > (const_int 41) > (const_int 2) > (const_int 42) > ] > ]) > >There are probably better syntaxes, but hopefully this is at least >an improvement on the status quo. > >Tested on aarch64-linux-gnu, arm-linux-gnueabihf, armeb-eabi >and x86_64-linux-gnu. OK to install now, or should it wait >until GCC 12? (It only affects SVE in practice.) Ok now (it should be harmless, no?) Thanks, Richard. >Richard > > >gcc/ > * print-rtl.c (rtx_writer::print_rtx_operand_codes_E_and_V): Print > more information about variable-length CONST_VECTORs. >--- > gcc/print-rtl.c | 32 +++++++++++++++++++++++++++++++- > 1 file changed, 31 insertions(+), 1 deletion(-) > >diff --git a/gcc/print-rtl.c b/gcc/print-rtl.c >index c7982bce507..081fc50fab8 100644 >--- a/gcc/print-rtl.c >+++ b/gcc/print-rtl.c >@@ -370,6 +370,10 @@ rtx_writer::print_rtx_operand_codes_E_and_V >(const_rtx in_rtx, int idx) > print_rtx_head, m_indent * 2, ""); > m_sawclose = 0; > } >+ if (GET_CODE (in_rtx) == CONST_VECTOR >+ && !GET_MODE_NUNITS (GET_MODE (in_rtx)).is_constant () >+ && CONST_VECTOR_DUPLICATE_P (in_rtx)) >+ fprintf (m_outfile, " repeat"); > fputs (" [", m_outfile); > if (XVEC (in_rtx, idx) != NULL) > { >@@ -377,12 +381,32 @@ rtx_writer::print_rtx_operand_codes_E_and_V >(const_rtx in_rtx, int idx) > if (XVECLEN (in_rtx, idx)) > m_sawclose = 1; > >+ int barrier = XVECLEN (in_rtx, idx); >+ if (GET_CODE (in_rtx) == CONST_VECTOR >+ && !GET_MODE_NUNITS (GET_MODE (in_rtx)).is_constant ()) >+ barrier = CONST_VECTOR_NPATTERNS (in_rtx); >+ > for (int j = 0; j < XVECLEN (in_rtx, idx); j++) > { > int j1; > >+ if (j == barrier) >+ { >+ fprintf (m_outfile, "\n%s%*s", >+ print_rtx_head, m_indent * 2, ""); >+ if (!CONST_VECTOR_STEPPED_P (in_rtx)) >+ fprintf (m_outfile, "repeat ["); >+ else if (CONST_VECTOR_NPATTERNS (in_rtx) == 1) >+ fprintf (m_outfile, "stepped ["); >+ else >+ fprintf (m_outfile, "stepped (interleave %d) [", >+ CONST_VECTOR_NPATTERNS (in_rtx)); >+ m_indent += 2; >+ } >+ > print_rtx (XVECEXP (in_rtx, idx, j)); >- for (j1 = j + 1; j1 < XVECLEN (in_rtx, idx); j1++) >+ int limit = MIN (barrier, XVECLEN (in_rtx, idx)); >+ for (j1 = j + 1; j1 < limit; j1++) > if (XVECEXP (in_rtx, idx, j) != XVECEXP (in_rtx, idx, j1)) > break; > >@@ -393,6 +417,12 @@ rtx_writer::print_rtx_operand_codes_E_and_V >(const_rtx in_rtx, int idx) > } > } > >+ if (barrier < XVECLEN (in_rtx, idx)) >+ { >+ m_indent -= 2; >+ fprintf (m_outfile, "\n%s%*s]", print_rtx_head, m_indent * 2, ""); >+ } >+ > m_indent -= 2; > } > if (m_sawclose)
Richard Biener <richard.guenther@gmail.com> writes: > On April 14, 2021 5:10:26 PM GMT+02:00, Richard Sandiford via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: >>Looking at PR99929 showed that we weren't dumping enough information >>about variable-length CONST_VECTORs. Something like: >> >> (const_vector:VNx4SI [(const_int 1) (const_int 0)]) >> >>could be either: >> >>(a) 1, 0, 1, 0, repeating >>(b) 1 followed by all zeros >> >>This patch adds more information to the dumps. There are four cases: >> >>(a) above: >> >> (const_vector:VNx4SI repeat [ >> (const_int 1) >> (const_int 0) >> ]) >> >>(b) above: >> >> (const_vector:VNx4SI [ >> (const_int 1) >> repeat [ >> (const_int 0) >> ] >> ]) >> >>a single stepped sequence: >> >> (const_vector:VNx4SI [ >> (const_int 0) >> stepped [ >> (const_int 1) >> (const_int 2) >> ] >> ]) >> >>interleaved stepped sequences: >> >> (const_vector:VNx4SI [ >> (const_int 0) >> (const_int 40) >> stepped (interleave 2) [ >> (const_int 1) >> (const_int 41) >> (const_int 2) >> (const_int 42) >> ] >> ]) >> >>There are probably better syntaxes, but hopefully this is at least >>an improvement on the status quo. >> >>Tested on aarch64-linux-gnu, arm-linux-gnueabihf, armeb-eabi >>and x86_64-linux-gnu. OK to install now, or should it wait >>until GCC 12? (It only affects SVE in practice.) > > Ok now (it should be harmless, no?) Yeah, I hope so :-) Thanks, Richard
diff --git a/gcc/print-rtl.c b/gcc/print-rtl.c index c7982bce507..081fc50fab8 100644 --- a/gcc/print-rtl.c +++ b/gcc/print-rtl.c @@ -370,6 +370,10 @@ rtx_writer::print_rtx_operand_codes_E_and_V (const_rtx in_rtx, int idx) print_rtx_head, m_indent * 2, ""); m_sawclose = 0; } + if (GET_CODE (in_rtx) == CONST_VECTOR + && !GET_MODE_NUNITS (GET_MODE (in_rtx)).is_constant () + && CONST_VECTOR_DUPLICATE_P (in_rtx)) + fprintf (m_outfile, " repeat"); fputs (" [", m_outfile); if (XVEC (in_rtx, idx) != NULL) { @@ -377,12 +381,32 @@ rtx_writer::print_rtx_operand_codes_E_and_V (const_rtx in_rtx, int idx) if (XVECLEN (in_rtx, idx)) m_sawclose = 1; + int barrier = XVECLEN (in_rtx, idx); + if (GET_CODE (in_rtx) == CONST_VECTOR + && !GET_MODE_NUNITS (GET_MODE (in_rtx)).is_constant ()) + barrier = CONST_VECTOR_NPATTERNS (in_rtx); + for (int j = 0; j < XVECLEN (in_rtx, idx); j++) { int j1; + if (j == barrier) + { + fprintf (m_outfile, "\n%s%*s", + print_rtx_head, m_indent * 2, ""); + if (!CONST_VECTOR_STEPPED_P (in_rtx)) + fprintf (m_outfile, "repeat ["); + else if (CONST_VECTOR_NPATTERNS (in_rtx) == 1) + fprintf (m_outfile, "stepped ["); + else + fprintf (m_outfile, "stepped (interleave %d) [", + CONST_VECTOR_NPATTERNS (in_rtx)); + m_indent += 2; + } + print_rtx (XVECEXP (in_rtx, idx, j)); - for (j1 = j + 1; j1 < XVECLEN (in_rtx, idx); j1++) + int limit = MIN (barrier, XVECLEN (in_rtx, idx)); + for (j1 = j + 1; j1 < limit; j1++) if (XVECEXP (in_rtx, idx, j) != XVECEXP (in_rtx, idx, j1)) break; @@ -393,6 +417,12 @@ rtx_writer::print_rtx_operand_codes_E_and_V (const_rtx in_rtx, int idx) } } + if (barrier < XVECLEN (in_rtx, idx)) + { + m_indent -= 2; + fprintf (m_outfile, "\n%s%*s]", print_rtx_head, m_indent * 2, ""); + } + m_indent -= 2; } if (m_sawclose)
Looking at PR99929 showed that we weren't dumping enough information about variable-length CONST_VECTORs. Something like: (const_vector:VNx4SI [(const_int 1) (const_int 0)]) could be either: (a) 1, 0, 1, 0, repeating (b) 1 followed by all zeros This patch adds more information to the dumps. There are four cases: (a) above: (const_vector:VNx4SI repeat [ (const_int 1) (const_int 0) ]) (b) above: (const_vector:VNx4SI [ (const_int 1) repeat [ (const_int 0) ] ]) a single stepped sequence: (const_vector:VNx4SI [ (const_int 0) stepped [ (const_int 1) (const_int 2) ] ]) interleaved stepped sequences: (const_vector:VNx4SI [ (const_int 0) (const_int 40) stepped (interleave 2) [ (const_int 1) (const_int 41) (const_int 2) (const_int 42) ] ]) There are probably better syntaxes, but hopefully this is at least an improvement on the status quo. Tested on aarch64-linux-gnu, arm-linux-gnueabihf, armeb-eabi and x86_64-linux-gnu. OK to install now, or should it wait until GCC 12? (It only affects SVE in practice.) Richard gcc/ * print-rtl.c (rtx_writer::print_rtx_operand_codes_E_and_V): Print more information about variable-length CONST_VECTORs. --- gcc/print-rtl.c | 32 +++++++++++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-)