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
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 inst
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 -
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.
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_sr
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 propagatio
