From jkarthikeyan at openjdk.org Wed Nov 1 01:28:04 2023 From: jkarthikeyan at openjdk.org (Jasmine Karthikeyan) Date: Wed, 1 Nov 2023 01:28:04 GMT Subject: RFR: 8318683: compiler/c2/irTests/TestPhiDuplicatedConversion.java "Failed IR Rules (2) of Methods (2)" In-Reply-To: <-InlyNGFkQnEFLhI5RpF50ALllBz9twVSSo5nx5X1JE=.181478f6-0e3b-40e5-b2a1-b4e681382aaa@github.com> References: <-InlyNGFkQnEFLhI5RpF50ALllBz9twVSSo5nx5X1JE=.181478f6-0e3b-40e5-b2a1-b4e681382aaa@github.com> Message-ID: On Thu, 26 Oct 2023 12:29:44 GMT, Jasmine Karthikeyan wrote: > This patch should fix the testbug where F16 conversions were expected but were not supported by the CPU. Instead of checking for AVX, I now check for `f16c` or `avx512vl`, mirroring the logic in vm_version_x86: > https://github.com/openjdk/jdk/blob/ec1bf23d012f007c126cb472fcff146cf7f41b1a/src/hotspot/cpu/x86/vm_version_x86.hpp#L770-L772 > > I went with the approach of changing the logic in the IR annotation itself instead of the test requirements, as the majority of the IR tests in this file should complete correctly on other platforms. Tier 1 testing passes on my (linux x64) machine. Reviews would be appreciated! Thank you for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16378#issuecomment-1788256619 From fgao at openjdk.org Wed Nov 1 03:17:01 2023 From: fgao at openjdk.org (Fei Gao) Date: Wed, 1 Nov 2023 03:17:01 GMT Subject: RFR: 8315361: C2: Create a superclass of SuperWord [v2] In-Reply-To: References: <1TvO1Yb11BjAn4X6jux459nNuDfFrc_6-8lkHgcNigs=.8607af09-c25c-4f41-845c-c9a5900de1a0@github.com> <4Do087FyKv6Xjl1zHGIamOqR7YyS42S-dAtLLiH3CzA=.d046ad46-5105-4900-8e4f-eba9aaea0d34@github.com> Message-ID: On Mon, 30 Oct 2023 11:01:29 GMT, Emanuel Peter wrote: > My question: should we not also move the `velt` (vector element type) and maybe even the dependence graph parts? If I remember right, then the post-loop-vectorizer also needs some way to determine element type (`_elem_bt` [here](https://github.com/openjdk/jdk/pull/14581)), but not sure about dependence graph. And also the memory slices may be helpful for all vectorizers. We could also have more classes that have different parts of these features (eg. `Vectorizer` with only basic functionality, and then a `VectorizerWithDependencyGraph`). Hi @eme64, thanks for your review! Yes, and both SuperWord and post-loop-vectorizer need to determine vector element type. There are still some deficiencies in current [`compute_vector_element_type()`](https://github.com/openjdk/jdk/blob/b3fec6b5f32c338ae1a84dd20bdcbd3d9b7186f3/src/hotspot/share/opto/superword.cpp#L3350) of SuperWord. For example, some loop cases of subword types, including byte and short, can't be recognized very well. See the description in https://github.com/openjdk/jdk/pull/7954. Maybe the main idea of [`find_vector_element_types()`](https://github.com/openjdk/jdk/blob/bd1b939b21a23675fd072b91d4eab538ff6d2a7d/src/hotspot/share/opto/vmaskloop.cpp#L318) proposed in Pengfei?s post-loop-vectorizer can be improved to solve it? About the dependence graph part, SuperWord works better than post-loop-vectorizer, because it can support more cases like reading-forward, after your great refactoring ? . But now, post-loop-vectorizer can?t support any cases with index offset. So, maybe both two parts need more complex refactoring and improving, before they can be shared well by two vectorizers, not like code parts in this patch. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/16353#issuecomment-1788340550 From jkarthikeyan at openjdk.org Wed Nov 1 06:16:13 2023 From: jkarthikeyan at openjdk.org (Jasmine Karthikeyan) Date: Wed, 1 Nov 2023 06:16:13 GMT Subject: Integrated: 8318683: compiler/c2/irTests/TestPhiDuplicatedConversion.java "Failed IR Rules (2) of Methods (2)" In-Reply-To: <-InlyNGFkQnEFLhI5RpF50ALllBz9twVSSo5nx5X1JE=.181478f6-0e3b-40e5-b2a1-b4e681382aaa@github.com> References: <-InlyNGFkQnEFLhI5RpF50ALllBz9twVSSo5nx5X1JE=.181478f6-0e3b-40e5-b2a1-b4e681382aaa@github.com> Message-ID: On Thu, 26 Oct 2023 12:29:44 GMT, Jasmine Karthikeyan wrote: > This patch should fix the testbug where F16 conversions were expected but were not supported by the CPU. Instead of checking for AVX, I now check for `f16c` or `avx512vl`, mirroring the logic in vm_version_x86: > https://github.com/openjdk/jdk/blob/ec1bf23d012f007c126cb472fcff146cf7f41b1a/src/hotspot/cpu/x86/vm_version_x86.hpp#L770-L772 > > I went with the approach of changing the logic in the IR annotation itself instead of the test requirements, as the majority of the IR tests in this file should complete correctly on other platforms. Tier 1 testing passes on my (linux x64) machine. Reviews would be appreciated! This pull request has now been integrated. Changeset: 2a76ad97 Author: Jasmine Karthikeyan Committer: Tobias Hartmann URL: https://git.openjdk.org/jdk/commit/2a76ad975c8612c19f6c1c8f5a996017f753cb66 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod 8318683: compiler/c2/irTests/TestPhiDuplicatedConversion.java "Failed IR Rules (2) of Methods (2)" Reviewed-by: thartmann, kvn ------------- PR: https://git.openjdk.org/jdk/pull/16378 From thartmann at openjdk.org Wed Nov 1 06:22:01 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 1 Nov 2023 06:22:01 GMT Subject: RFR: JDK-8318016: Per-compilation memory ceiling [v3] In-Reply-To: References: Message-ID: <1tG_UtpIhddMTRSmPrK1dc-B1BCoF0ZdrF4HIW2t64Y=.19fa8fd6-c471-494c-bb8b-b959a948cb40@github.com> On Fri, 27 Oct 2023 12:57:07 GMT, Thomas Stuefe wrote: >> This RFE introduces a new compile command to limit memory usage per compilation. It complements and is based upon the JIT memory statistic introduced with https://bugs.openjdk.org/browse/JDK-8317683. >> >> This new memory limit is applied during compilation for either C1 or C2. It has one of two modes: >> - *crash* mode (mainly for compiler devs), which aborts with hs-err file when the ceiling is reached, right in the compiler thread at the allocation point that triggered the ceiling >> - *stop* mode, which stops the compilation similarly to how hitting the node limit in C2 would stop the compilation. >> >> #### Usage >> >> The compile command takes the form `-XX:CompileCommand:MemLimit,,[~