[PATCH] include MEM_REF type in tree dumps (PR 90676)

Rainer Orth ro@CeBiTec.Uni-Bielefeld.DE
Wed Jun 12 21:34:00 GMT 2019


Richard Biener <richard.guenther@gmail.com> writes:

> On Mon, Jun 10, 2019 at 10:37 PM Martin Sebor <msebor@gmail.com> wrote:
>>
>> On 6/10/19 1:29 PM, Jakub Jelinek wrote:
>> > On Mon, Jun 10, 2019 at 01:23:28PM -0600, Martin Sebor wrote:
>> >> +  else if (integer_zerop (TREE_OPERAND (node, 1))
>> >> +       /* Dump the types of INTEGER_CSTs explicitly, for we can't
>> >> +          infer them and MEM_ATTR caching will share MEM_REFs
>> >> +          with differently-typed op0s.  */
>> >> +       && TREE_CODE (TREE_OPERAND (node, 0)) != INTEGER_CST
>> >> +       /* Released SSA_NAMES have no TREE_TYPE.  */
>> >> +       && TREE_TYPE (TREE_OPERAND (node, 0)) != NULL_TREE
>> >> +       /* Same pointer types, but ignoring POINTER_TYPE vs.
>> >> +          REFERENCE_TYPE.  */
>> >> +       && (TREE_TYPE (TREE_TYPE (TREE_OPERAND (node, 0)))
>> >> +           == TREE_TYPE (TREE_TYPE (TREE_OPERAND (node, 1))))
>> >> +       && (TYPE_MODE (TREE_TYPE (TREE_OPERAND (node, 0)))
>> >> +           == TYPE_MODE (TREE_TYPE (TREE_OPERAND (node, 1))))
>> >> +       && (TYPE_REF_CAN_ALIAS_ALL (TREE_TYPE (TREE_OPERAND (node, 0)))
>> >> +           == TYPE_REF_CAN_ALIAS_ALL (TREE_TYPE (TREE_OPERAND (node, 1))))
>> >> +       /* Same value types ignoring qualifiers.  */
>> >> +       && (TYPE_MAIN_VARIANT (TREE_TYPE (node))
>> >> +           == TYPE_MAIN_VARIANT
>> >> +           (TREE_TYPE (TREE_TYPE (TREE_OPERAND (node, 1)))))
>> >
>> > You should be using types_compatible_p rather than type equality, that is
>> > all GIMPLE cares about.
>>
>> The code above predates my change, I just factored it out into
>> a separate function; it does make the diff bigger.  The code
>> I introduced only adds the <...> if the size of the access
>> differs from the size of the operand. I used type sizes rather
>> than testing their compatibility to minimize the number of tests
>> that might need updating.
>>
>> This is the salient bit:
>>
>> +      pp_string (pp, "MEM");
>> +
>> +      tree nodetype = TREE_TYPE (node);
>> +      tree op0 = TREE_OPERAND (node, 0);
>> +      tree op1 = TREE_OPERAND (node, 1);
>> +      tree op1type = TYPE_MAIN_VARIANT (TREE_TYPE (op1));
>> +
>> +      if (!tree_int_cst_equal (TYPE_SIZE (nodetype),
>> +                              TYPE_SIZE (TREE_TYPE (op1type))))
>> +       {
>> +         pp_string (pp, " <");
>> +         /* If the size of the type of the operand is not the same
>> +            as the size of the MEM_REF expression include the type
>> +            of the latter similar to the TDF_GIMPLE output to make
>> +            it clear how many bytes of memory are being accessed.  */
>> +         dump_generic_node (pp, nodetype, spc, flags | TDF_SLIM, false);
>> +         pp_string (pp, "> ");
>> +       }
>
> You need to guard against non-constant TYPE_SIZE here (for both
> involved types) so I suggest you use operand_equal_p (..., 0).  If you
> do that you need to guard against NULL_TREE TYPE_SIZE
> (tree_int_cst_equal handled that as unequal).
>
> OK with such change.
> Richard.

The testsuite part cannot have been tested very thoroughly: for one,
this snippet

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-24.c b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-24.c
--- a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-24.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-24.c
@@ -59,4 +59,5 @@ void foo(int prec,
     bar (&info);
 }
 
-/* { dg-final { scan-tree-dump-times "MEM\\\[\\(struct printf_info \\*\\)&info \\+ \[0-9\]+B\\\] = {}" 1 "dse1" } } */
+/* { dg-final { scan-tree-dump-times "MEM\\\[\\(struct printf_info \\*\\)&info \\+ \[0-9\]+B\\\] = {}" 1 "dse1" { target { ! store_merge } } } }
+   { dg-final { scan-tree-dump-times "MEM <char[4]> \\\[\\(struct printf_info \\*\\)&info \\+ \[0-9\]+B\\\] = {}" 1 "dse1" { target { store_merge } } } } */


breaks gcc.sum creation with dg-extract-result.py (the default)
completely: gcc.log shows

spawn -ignore SIGHUP /var/gcc/regression/trunk/11-gcc/build/gcc/xgcc -B/var/gcc/regression/trunk/11-gcc/build/gcc/ /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-24.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O2 -fdump-tree-dse1 -S -o ssa-dse-24.s^M
PASS: gcc.dg/tree-ssa/ssa-dse-24.c (test for excess errors)
ERROR: (DejaGnu) proc "4" does not exist.
The error code is NONE
The info on the error is:
invalid command name "4"
    while executing
"::tcl_unknown 4"
    ("uplevel" body line 1)
    invoked from within
"uplevel 1 ::tcl_unknown $args"

due to the unquoted [4].

Even with that fixed, I see many failures:

+FAIL: g++.dg/tree-ssa/pr31146.C  -std=gnu++14  scan-tree-dump forwprop1 "MEM\\\\[.*&i\\\\]\\\\[j.*\\\\] =.* 1;"
+FAIL: g++.dg/tree-ssa/pr31146.C  -std=gnu++17  scan-tree-dump forwprop1 "MEM\\\\[.*&i\\\\]\\\\[j.*\\\\] =.* 1;"
+FAIL: g++.dg/tree-ssa/pr31146.C  -std=gnu++98  scan-tree-dump forwprop1 "MEM\\\\[.*&i\\\\]\\\\[j.*\\\\] =.* 1;"
+FAIL: g++.dg/tree-ssa/ssa-dse-1.C   scan-tree-dump-times dse1 "MEM <char\\\\[176]> \\\\[\\\\(struct FixBuf \\\\*\\\\)&<retval> \\\\+ [0-9]+B\\\\] = {}" 1

on 32 and 64-bit i386-pc-solaris2.11 (and i686-pc-linux-gnu),

+FAIL: g++.dg/tree-ssa/pr19807.C  -std=gnu++14  scan-tree-dump-times optimized "&MEM\\\\[\\\\(void .\\\\)&a \\\\+ 8B\\\\]" 3
+FAIL: g++.dg/tree-ssa/pr19807.C  -std=gnu++17  scan-tree-dump-times optimized "&MEM\\\\[\\\\(void .\\\\)&a \\\\+ 8B\\\\]" 3
+FAIL: g++.dg/tree-ssa/pr19807.C  -std=gnu++98  scan-tree-dump-times optimized "&MEM\\\\[\\\\(void .\\\\)&a \\\\+ 8B\\\\]" 3

+FAIL: gcc.dg/tree-prof/stringop-2.c scan-tree-dump optimized "MEM\\\\[\\\\(void .\\\\)&a\\\\] = 168430090"
+FAIL: gcc.dg/tree-ssa/pr30375.c scan-tree-dump-times dse1 "MEM\\\\[\\\\(struct _s \\\\*\\\\)&signInfo \\\\+ [0-9]+B\\\\] = {}" 1
+FAIL: gcc.dg/tree-ssa/slsr-27.c scan-tree-dump-times dom3 "MEM\\\\[\\\\(struct x \\\\*\\\\)[^\\r\\n]*_\\\\d+" 3
+FAIL: gcc.dg/tree-ssa/slsr-28.c scan-tree-dump-times dom3 "MEM\\\\[\\\\(struct x \\\\*\\\\)[^\\r\\n]*_\\\\d+" 9
+FAIL: gcc.dg/tree-ssa/slsr-29.c scan-tree-dump-times dom3 "MEM\\\\[\\\\(struct x \\\\*\\\\)[^\\r\\n]*_\\\\d+" 9
+FAIL: gcc.dg/tree-ssa/ssa-dse-24.c scan-tree-dump-times dse1 "MEM\\\\[\\\\(struct printf_info \\\\*\\\\)&info \\\\+ [0-9]+B\\\\] = {}" 1

on 32 and 64-bit sparc-sun-solaris2.11 (the first of those also on
m68k-unknown-linux-gnu).

I haven't even started looking what's wrong (quoting problems in the REs
or other issues).

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University



More information about the Gcc-patches mailing list