RFR: 8331090: Run Ideal_minmax before de-canonicalizing CMoves

[Jasmine Karthikeyan]

Hi all,
This patch aims to solve some CMove min/max patterns not being recognized due to the BoolNode comparison being non-canonical, as was reported in [#18824](https://github.com/openjdk/jdk/pull/18824). This can occur due to other Ideal transforms done by CMoves, such as in [here](https://github.com/openjdk/jdk/blob/efb905e57ab7a5299952419fa9961316541056c2/src/hotspot/share/opto/movenode.cpp#L95-L97) and [here](https://github.com/openjdk/jdk/blob/efb905e57ab7a5299952419fa9961316541056c2/src/hotspot/share/opto/movenode.cpp#L274-L278). These transforms move constants and zero-types to the right hand side of the CMove by flipping the comparison, potentially de-canonicalizing it. These invariants are used later on in the [ad files](https://github.com/openjdk/jdk/blob/efb905e57ab7a5299952419fa9961316541056c2/src/hotspot/cpu/x86/x86_64.ad#L6127-L6130) to emit more optimized assembly for these patterns. Since these existing patterns are useful to have, I think the best way to solve this would be
  to move `Ideal_minmax` before the branches are swapped and the BoolNode is negated. This should increase the set of inputs that the idealization is able to transform.

Tier 1-3 testing passes on my machine. Reviews and comments would be appreciated!

-------------

Commit messages:
 - Move Min/Max opt before CMove de-canonicalization

Changes: https://git.openjdk.org/jdk/pull/19914/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19914&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331090
  Stats: 42 lines in 2 files changed: 34 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19914.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19914/head:pull/19914

PR: https://git.openjdk.org/jdk/pull/19914