| Message ID | 22dddcdd-d739-4c6d-8da7-d59be94c435f@linux.ibm.com |
|---|---|
| State | New |
| Headers | show |
| Series | fwprop: Avoid volatile defines to be propagated | expand |
On 2/25/24 20:30, HAO CHEN GUI wrote: > Hi, > This patch tries to fix a potential problem which is raised by the patch > for PR111267. The volatile asm operand tries to be propagated to a single > set insn with the patch for PR111267. It has potential risk as the behavior > is wrong. Currently set_src_cost comparison can reject such propagation. > But the propagation might be taken after replacing set_src_cost with insn > cost. Actually I found the problem in testing my patch which replacing > et_src_cost with insn cost for fwprop. > > Bootstrapped and tested on x86 and powerpc64-linux BE and LE with no > regressions. Is it OK for the trunk? > > Thanks > Gui Haochen > > ChangeLog > fwprop: Avoid volatile defines to be propagated > > The patch for PR111267 (commit id 86de9b66480b710202a2898cf513db105d8c432f) > which introduces an exception for propagation on single set insn. The > propagation which might not be profitable (checked by profitable_p) is still > allowed to be propagated to single set insn. It has a potential problem > that a volatile asm operand will try to be propagated to a single set insn. > The volatile asm operand is originally banned in profitable_p. This patch > fixes the problem by skipping volatile set source in define set finding. > > gcc/ > * fwprop.cc (forward_propagate_into): Return false for volatile set > source. > > gcc/testsuite/ > * gcc.target/powerpc/fwprop-1.c: New. Why specifically are you worried here? Propagation of a volatile shouldn't in and of itself cause a problem. We're not changing the number of volatile accesses or anything like that -- we're just moving them around a bit. Jeff
Hi Jeff,
Thanks for your comments.
在 2024/3/4 6:02, Jeff Law 写道:
> Why specifically are you worried here? Propagation of a volatile shouldn't in and of itself cause a problem. We're not changing the number of volatile accesses or anything like that -- we're just moving them around a bit.
If the volatile asm operand is in a parallel set, it can't be eliminated
after the propagation. So the define insn and use insn will execute the
volatile asm block twice. That's the problem.
Here is a real case from sanitizer_linux.cpp. The insn 62 has a volatile
asm operands and it is propagated into insn 60. After propagation both
insn 60 and 62 has the volatile asm operand. Thus asm block will be
executed for twice. It causes sanitizer behaves abnormally in my test.
propagating insn 62 into insn 60, replacing:
(set (reg/v:DI 119 [ res ])
(reg:DI 133 [ res ]))
successfully matched this instruction:
(set (reg/v:DI 119 [ res ])
(asm_operands/v:DI ("mr 28, %5
mr 27, %8
mr 3, %7
mr 5, %9
mr 6, %10
mr 7, %11
li 0, %3
sc
cmpdi cr1, 3, 0
crandc cr1*4+eq, cr1*4+eq, cr0*4+so
bne- cr1, 1f
li 29, 0
stdu 29, -8(1)
stdu 1, -%12(1)
std 2, %13(1)
mr 12, 28
mtctr 12
mr 3, 27
bctrl
ld 2, %13(1)
li 0, %4
sc
1:
mr %0, 3
") ("=r") 0 [
(reg:SI 134)
(const_int 22 [0x16])
(const_int 120 [0x78])
(const_int 1 [0x1])
(reg/v:DI 3 3 [ __fn ])
(reg/v:DI 4 4 [ __cstack ])
(reg/v:SI 5 5 [ __flags ])
(reg/v:DI 6 6 [ __arg ])
(reg/v:DI 7 7 [ __ptidptr ])
(reg/v:DI 8 8 [ __newtls ])
(reg/v:DI 9 9 [ __ctidptr ])
(const_int 32 [0x20])
(const_int 24 [0x18])
[
(asm_input:SI ("0") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:SI ("i") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:SI ("i") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:SI ("i") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:DI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:DI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:SI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:DI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:DI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:DI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:DI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
]
[] /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591))
rescanning insn with uid = 60.
updating insn 60 in-place
(insn 62 61 60 6 (parallel [
(set (reg:DI 133 [ res ])
(asm_operands/v:DI ("mr 28, %5
mr 27, %8
mr 3, %7
mr 5, %9
mr 6, %10
mr 7, %11
li 0, %3
sc
cmpdi cr1, 3, 0
crandc cr1*4+eq, cr1*4+eq, cr0*4+so
bne- cr1, 1f
li 29, 0
stdu 29, -8(1)
stdu 1, -%12(1)
std 2, %13(1)
mr 12, 28
mtctr 12
mr 3, 27
bctrl
ld 2, %13(1)
li 0, %4
sc
1:
mr %0, 3
") ("=r") 0 [
(reg:SI 134)
(const_int 22 [0x16])
(const_int 120 [0x78])
(const_int 1 [0x1])
(reg/v:DI 3 3 [ __fn ])
(reg/v:DI 4 4 [ __cstack ])
(reg/v:SI 5 5 [ __flags ])
(reg/v:DI 6 6 [ __arg ])
(reg/v:DI 7 7 [ __ptidptr ])
(reg/v:DI 8 8 [ __newtls ])
(reg/v:DI 9 9 [ __ctidptr ])
(const_int 32 [0x20])
(const_int 24 [0x18])
]
[
(asm_input:SI ("0") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:SI ("i") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:SI ("i") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:SI ("i") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:DI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:DI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:SI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:DI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:DI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:DI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
(asm_input:DI ("r") /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591)
]
[] /home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp:1591))
(clobber (reg:DI 29 29))
(clobber (reg:DI 28 28))
(clobber (reg:DI 27 27))
(clobber (reg:DI 0 0))
(clobber (reg:DI 97 ctr))
(clobber (mem:BLK (scratch) [0 A8]))
(clobber (reg:CC 101 1))
(clobber (reg:CC 100 0))
(clobber (reg:SI 98 ca))
]) "/home/guihaoc/gcc/gcc-mainline-base/libsanitizer/sanitizer_common/sanitizer_linux.cpp":1591:2 -1
(expr_list:REG_DEAD (reg:SI 134)
(expr_list:REG_DEAD (reg/v:DI 9 9 [ __ctidptr ])
(expr_list:REG_DEAD (reg/v:DI 8 8 [ __newtls ])
(expr_list:REG_DEAD (reg/v:DI 7 7 [ __ptidptr ])
(expr_list:REG_DEAD (reg/v:DI 6 6 [ __arg ])
(expr_list:REG_DEAD (reg/v:SI 5 5 [ __flags ])
(expr_list:REG_DEAD (reg/v:DI 4 4 [ __cstack ])
(expr_list:REG_DEAD (reg/v:DI 3 3 [ __fn ])
(expr_list:REG_UNUSED (reg:CC 101 1)
(expr_list:REG_UNUSED (reg:CC 100 0)
(expr_list:REG_UNUSED (reg:SI 98 ca)
(expr_list:REG_UNUSED (reg:DI 97 ctr)
(expr_list:REG_UNUSED (reg:DI 29 29)
(expr_list:REG_UNUSED (reg:DI 28 28)
(expr_list:REG_UNUSED (reg:DI 27 27)
(expr_list:REG_UNUSED (reg:DI 0 0)
(nil))))))))))))))))))
Thanks
Gui Haochen
On 3/3/24 19:56, HAO CHEN GUI wrote: > Hi Jeff, > Thanks for your comments. > > 在 2024/3/4 6:02, Jeff Law 写道: >> Why specifically are you worried here? Propagation of a volatile shouldn't in and of itself cause a problem. We're not changing the number of volatile accesses or anything like that -- we're just moving them around a bit. > > If the volatile asm operand is in a parallel set, it can't be eliminated > after the propagation. So the define insn and use insn will execute the > volatile asm block twice. That's the problem. Thanks. That's a key piece of information. > > Here is a real case from sanitizer_linux.cpp. The insn 62 has a volatile > asm operands and it is propagated into insn 60. After propagation both > insn 60 and 62 has the volatile asm operand. Thus asm block will be > executed for twice. It causes sanitizer behaves abnormally in my test. Understood. So the key is that if we propagate an operand, but are unable to eliminate the original insn, then we can evaluate the operand (in this case an ASM) more than once? Can the same thing happen with a volatile memory load? I don't think that will be caught by the volatile_insn_p check. Jeff
Hi Jeff,
在 2024/3/4 11:37, Jeff Law 写道:
> Can the same thing happen with a volatile memory load? I don't think that will be caught by the volatile_insn_p check.
Yes, I think so. If the define rtx contains volatile memory references, it
may hit the same problem. We may use volatile_refs_p instead of
volatile_insn_p?
Thanks
Gui Haochen
On 3/4/24 02:12, HAO CHEN GUI wrote: > Hi Jeff, > > 在 2024/3/4 11:37, Jeff Law 写道: >> Can the same thing happen with a volatile memory load? I don't think that will be caught by the volatile_insn_p check. > > Yes, I think so. If the define rtx contains volatile memory references, it > may hit the same problem. We may use volatile_refs_p instead of > volatile_insn_p? Yea. OK with that change. Thanks, jeff
diff --git a/gcc/fwprop.cc b/gcc/fwprop.cc index 7872609b336..89dce88b43d 100644 --- a/gcc/fwprop.cc +++ b/gcc/fwprop.cc @@ -854,6 +854,8 @@ forward_propagate_into (use_info *use, bool reg_prop_only = false) rtx dest = SET_DEST (def_set); rtx src = SET_SRC (def_set); + if (volatile_insn_p (src)) + return false; /* Allow propagations into a loop only for reg-to-reg copies, since replacing one register by another shouldn't increase the cost. diff --git a/gcc/testsuite/gcc.target/powerpc/fwprop-1.c b/gcc/testsuite/gcc.target/powerpc/fwprop-1.c new file mode 100644 index 00000000000..07b207f980c --- /dev/null +++ b/gcc/testsuite/gcc.target/powerpc/fwprop-1.c @@ -0,0 +1,15 @@ +/* { dg-do compile } */ +/* { dg-options "-O1 -fdump-rtl-fwprop1-details" } */ +/* { dg-final { scan-rtl-dump-not "propagating insn" "fwprop1" } } */ + +/* Verify that volatile asm operands doesn't try to be propagated. */ +long long foo () +{ + long long res; + __asm__ __volatile__( + "" + : "=r" (res) + : + : "memory"); + return res; +}