On 09/16/2016 03:19 PM, David Malcolm wrote:
When possible I don't think we want the tests to be target specific.
Hmm, I'm probably about to argue for Bernd's work... The 71779
testcase
is a great example -- it uses high/lo_sum. Not all targets support
that
-- as long as we don't try to recognize those insns we're likely OK,
but
that seems fragile long term. Having an idealized target means we
can
ignore much of these issues.
An alternative would be to pick a specific target for each test.
It's an alternative, but not one I particularly like since those tests
won't be consistently run. With an abstracted target like Bernd
suggests we ought to be able to make most tests work with the abstracted
target and minimize the number of truely target specific tests.
So I'm real curious, what happens if you run this RTL selftest under
valgrind? I have the sneaking suspicion that we'll start doing some
uninitialized memory reads.
I'm seeing various leaks (an htab within linemap_init for all of the
line_table fixtures), but no uninitialized reads.
Wow. I must say I'm surprised. Good news though.
+
+ /* Dump taken from comment 2 of PR 71779, of
+ "...the relevant memory access coming out of expand"
+ with basic block IDs added, and prev/next insns set to
+ 0 at ends. */
+ const char *input_dump
+ = (";; MEM[(struct isl_obj *)&obj1] = &isl_obj_map_vtable;\n"
+ "(insn 1045 0 1046 2 (set (reg:SI 480)\n"
+ " (high:SI (symbol_ref:SI (\"isl_obj_map_vtable\")
[flags 0xc0] <var_decl 0x7fa0363ea240 isl_obj_map_vtable>)))
y.c:12702 -1\n"
+ " (nil))\n"
+ "(insn 1046 1045 1047 2 (set (reg/f:SI 479)\n"
+ " (lo_sum:SI (reg:SI 480)\n"
+ " (symbol_ref:SI (\"isl_obj_map_vtable\") [flags
0xc0] <var_decl 0x7fa0363ea240 isl_obj_map_vtable>))) y.c:12702
-1\n"
+ " (expr_list:REG_EQUAL (symbol_ref:SI
(\"isl_obj_map_vtable\") [flags 0xc0] <var_decl 0x7fa0363ea240
isl_obj_map_vtable>)\n"
+ " (nil)))\n"
+ "(insn 1047 1046 1048 2 (set (reg:DI 481)\n"
+ " (subreg:DI (reg/f:SI 479) 0)) y.c:12702 -1\n"
+ " (nil))\n"
+ "(insn 1048 1047 1049 2 (set (zero_extract:DI (reg/v:DI 191
[ obj1D.17368 ])\n"
+ " (const_int 32 [0x20])\n"
+ " (const_int 0 [0]))\n"
+ " (reg:DI 481)) y.c:12702 -1\n"
+ " (nil))\n"
So looking at this just makes my head hurt. Escaping, lots of
quotes,
unnecessary things in the dump, etc. The question I would have is
why
not have a file with the dump and read the file?
(nods)
Seems like I need to add a mechanism for telling the selftests which
directory to load the tests relative to.
What about putting them inside the appropriate gcc.target directories?
We could have one for the "generic" target assuming we build something
like that, the others could live in their target specific directory.
jeff
