@@ -511,8 +511,6 @@ int dominates(pseudo_t pseudo, struct instruction *insn, struct instruction *dom
return -1;
}
if (!same_memop(insn, dom)) {
- if (dom->opcode == OP_LOAD)
- return 0;
if (!overlapping_memop(insn, dom))
return 0;
return -1;
new file mode 100644
@@ -0,0 +1,29 @@
+union u {
+ double d;
+ int i[2];
+};
+
+void use(union u);
+
+int foo(double x, double y)
+{
+ union u u;
+ int r;
+
+ u.d = x;
+ r = u.i[0];
+ u.d = y;
+
+ use(u);
+ return r;
+}
+
+/*
+ * check-name: partial-load00
+ * check-command: test-linearize -Wno-decl $file
+ *
+ * check-output-ignore
+ * check-output-contains: store\\.
+ * check-output-contains: load\\.
+ * check-output-returns: %r2
+ */
When a partial but overlapping load is followed by a store, this load is not considered as dominating the store. This is a problem for kill_dominated_stores() because the load will be simply ignored. For example, in code like: union { u64 l; int i; } u; int i; u.l = x; i = u.i; u.l = y; The load will be ignored, then the first store can be ignored too and the value of 'i' will be undefined (but actually set to 0). The root of the problem seems to be situated in dominates() where a load is considered as dominating another memop only if both correspond to the same 'access' (address and size). This is probably fine when the other memop is itself a load (because the value of the first load can't be reused for the second one) but it's not when the other memop if a store. So, to be safe, consider different-but-overlapping memops as neither dominated or non-dominated but as "don't know". Note: as explained here above, this can *probably* be relaxed when both memops are loads but it's not 100% clear to me yet and I found no examples where it actually make a difference. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> --- flow.c | 2 -- validation/memops/partial-load00.c | 29 +++++++++++++++++++++++++++++ 2 files changed, 29 insertions(+), 2 deletions(-) create mode 100644 validation/memops/partial-load00.c