On Tue, Oct 28, 2025 at 1:26 PM Uros Bizjak <[email protected]> wrote: > > On Mon, Oct 27, 2025 at 11:56 PM H.J. Lu <[email protected]> wrote: > > > > > > IMO the -fcombine-op-with-volatile-memory-load is quite a bad name. > > > > > Options should have names that mean something to users. As this > > > > > seems to > > > > > supposed to be a target opt-in I'd suggest to not expose this to users > > > > > (or if targets are concerned, via some -m...) but instead make this a > > > > > > > > -mvolatile-memory-load? > > > > > > -mfuse-ops-with-volatile-access? > > > > > > So as to eventually also allow RMW? > > > > Yes. We can add the LOCK prefix for RMW if it is allowed. But will it > > improve performance? The LOCK prefix may be expensive. > > No, you don't need the LOCK prefix for volatile RMW access. LOCK is > needed for inter-thread synchronization, which is orthogonal to RMW > access. > > What Richard mentions is something like PR3506 [1], a step further > from propagating memory input, where also memory output is propagated > to form the instruction with RMW access. As an example, maybe you want > to increase the value stored at some memory-mapped IO. The location > has to be marked volatile, otherwise optimizers can figure out that > the memory location is unused and simply remove the update of "unused" > location. > > So, in the PR it is argued that: > > movl y, %eax > incl %eax > movl %eax, y > > access to volatile location is the same as: > > incl y > > and that the latter does not violate volatile correctness. > > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3506 > > Uros.
This can be a followup patch. -- H.J.
