On 11/26/25 5:54 PM, H.J. Lu wrote:
Volatile memory can be used as source operand for any operations. Add
-ffuse-ops-with-volatile-access to fuse operations with volatile memory
reference and update simplify_binary_operation_1 to keep PLUS for 2
volatile memory references. On x86, this optimizes
Presumably the plan is to add more operators in the future? It's
really not even clear why this hunk was needed.
Tested with Linux kernel 6.17.9 on Intel Core i7-1195G7.
gcc/
PR target/122343
* common.opt: Add -ffuse-ops-with-volatile-access.
* common.opt.urls: Regenerated.
* recog.cc (general_operand): Allow volatile memory reference if
-ffuse-ops-with-volatile-access is enabled.
* simplify-rtx.cc (simplify_binary_operation_1): Keep PLUS for 2
volatile memory references.
* doc/invoke.texi: Document -ffuse-ops-with-volatile-access.
+ffuse-ops-with-volatile-access
+Target Var(flag_fuse_ops_with_volatile_access) Init(1)
+Allow operations with volatile memory access in the combine pass.
So end users won't really know what the "combine pass" means and I dont
think the statement is really all that accurate given those routines are
used outside combine.
So how about:
Allow limited optimization of operations with volatile memory access
when doing so does not change the semantics outlined in <???>.
Where <???> is whatever texinfo magic is necessary to point to the "When
is a Volatile Object Accessed" section of the manual (under extensions).
This will be OK with that change.
jeff
