On on Tue, 21 Jul 2026 16:55:07 +0200, Jakub Jelinek <[email protected]> wrote: > On Wed, Jun 10, 2026 at 07:38:14PM +0530, [email protected] wrote: >> From: Soumya AR <[email protected]> >> >> This patch adds a new pass that recognises compare-and-swap loops >> implementing >> an atomic fetch min or max, and replaces each one with a single >> IFN_ATOMIC_FETCH_MINMAX call. This allows us to emit a target optab for >> fetch >> min/max, if available. > > This definitely shouldn't be done in a separate pass. > Pattern match it where similar stuff is usually pattern-matched, forwprop, > phiopt, widening_mul, etc. > I think it shouldn't be matched if there is no corresponding optab > (especially if it is matched after IPA). I think it should be done after > IPA, while your current location is after einline and so if you're lucky > you get some possible inlines around the atomics inlined, you might not > get all of those until after IPA. >
For integer min/max, I agree. Placing this post-IPA also has the added benefit of only pattern-matching if the correct host/device backend is known (on top of inling small helpers with IPA). However, I don't think a post-IPA (only) approach is sufficient for FP atomics when the libstdc++ method uses an attribute such as [[gnu::ignore_fenv]], as pattern-matching needs to happen before the method is inlined. (More on the attribute here: https://gcc.gnu.org/pipermail/gcc-patches/2026-July/724243.html) Would it then make more sense to do this twice? For example, if this were made part of phiopt, we could handle these cases accordingly depending on whether we are currently pre- or post-IPA. ---- Just to double check, you mentioned pattern matching the integer min/max early here: gcc.gnu.org/pipermail/gcc-patches/2025-November/699611.html, was there any particular reason? We initially thought it was in order to avoid the possibility of missing cases post-IPA (as we mentioned here: gcc.gnu.org/pipermail/gcc-patches/2025-November/699887.html), but we're possibly wrong on that thought... (I was also not able to see any missed opportunities in my experiments.) Is there any specific positive to putting this pass earlier? ---- As for FP atomics, the current pass placement works because even though it is placed after einline, since we process callees before callers in this sequence, we can pattern-match the libsdc++ method first and then inline it into its caller. (Was able to confirm this with experiments on the existing fetch min/max code.) This comes with the assumption that if we can verify (after pattern-matching) that all other fenv-sensitive arithmetic in the fn is redundant, we can clear the attribute and not trip up subsequent inlining. Another possibility is for the attribute to only mean "can be pattern-matched" and not enable any other FP optimization. Since it has no effect on any other FP op, we could remove the attribute unconditionally. The trade-off being that we wouldn't be able to match user-written code. Just mentioning that we also do have a requirement for pattern-matching FP atomics post fre/dse/cd-dce. We need fre and dse to convert memcpy bit reinterpretations into VIEW_CONVERT_EXPR and cd-dce for removing unnecessary clobbers. Thanks, Soumya > Jakub
