unsubscribe
Zhang Li
jjshanwei at gmail.com
Mon May 29 02:04:50 UTC 2023
<hotspot-compiler-dev-request at openjdk.org>于2023年5月29日 周一09:01写道：
> Send hotspot-compiler-dev mailing list submissions to
> hotspot-compiler-dev at openjdk.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.openjdk.org/mailman/listinfo/hotspot-compiler-dev
> or, via email, send a message with subject or body 'help' to
> hotspot-compiler-dev-request at openjdk.org
>
> You can reach the person managing the list at
> hotspot-compiler-dev-owner at openjdk.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of hotspot-compiler-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: RFR: 8303451: Synchronization entry in C2 debug info is
> misleading [v2] (Daohan Qu)
> 2. RFR: 8308892: Bad graph detected in build_loop_late after
> JDK-8305635 (Christian Hagedorn)
> 3. Re: RFR: 8308915: RISC-V: Improve temporary vector register
> usage avoiding the use of v0 [v2] (Dingli Zhang)
> 4. Re: RFR: 8308915: RISC-V: Improve temporary vector register
> usage avoiding the use of v0 [v2] (Dingli Zhang)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 27 May 2023 16:34:15 GMT
> From: Daohan Qu <duke at openjdk.org>
> To: <hotspot-compiler-dev at openjdk.org>
> Subject: Re: RFR: 8303451: Synchronization entry in C2 debug info is
> misleading [v2]
> Message-ID:
> <6wyhvO-8OHzCY3yTorzYtIjR4Xvu2cVNX9pqvY9CZGQ=.
> c257dc76-7544-44b0-94ee-5c89a60c82ed at github.com>
>
> Content-Type: text/plain; charset=utf-8
>
> > This should fix [JDK-8303451](
> https://bugs.openjdk.org/browse/JDK-8303451).
> >
> > It is a trivial patch that fixes a misleading code comment at method
> entry printed by `-XX:+PrintAssembly`.
> >
> > For exmple,
> >
> > 0x0000ffffa409da88: stp x29, x30, [sp, #16] ;*synchronization
> entry
> >
> > will become
> >
> > 0x0000ffffa409da88: stp x29, x30, [sp, #16] ; * invocation
> entry (also synchronization entry if synchronized)
>
> Daohan Qu has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update output again
>
> -------------
>
> Changes:
> - all: https://git.openjdk.org/jdk/pull/14192/files
> - new: https://git.openjdk.org/jdk/pull/14192/files/2f21f37b..362fc750
>
> Webrevs:
> - full: https://webrevs.openjdk.org/?repo=jdk&pr=14192&range=01
> - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14192&range=00-01
>
> Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
> Patch: https://git.openjdk.org/jdk/pull/14192.diff
> Fetch: git fetch https://git.openjdk.org/jdk.git
> pull/14192/head:pull/14192
>
> PR: https://git.openjdk.org/jdk/pull/14192
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 28 May 2023 22:13:22 GMT
> From: Christian Hagedorn <chagedorn at openjdk.org>
> To: <hotspot-compiler-dev at openjdk.org>
> Subject: RFR: 8308892: Bad graph detected in build_loop_late after
> JDK-8305635
> Message-ID:
> <K2IRM4px9OtFtfV6RUs3omTtCp9b4gW44d2lWYymklc=.
> bf59e9e7-87b7-45c4-9c2d-701c813f6a0f at github.com>
>
> Content-Type: text/plain; charset=utf-8
>
> The cleanup done in [JDK-8305635](
> https://bugs.openjdk.org/browse/JDK-8305635) wrongly identifies unrelated
> Parse Predicates which are not cleaned up, yet. It just walks from the
> entry of the loop up and tries to find each of the three Parse Predicates
> once but in no particular order. This order insensitive walk is wrong as
> seen in the following graph (from the attached replay file of this bug):
>
> 
>
> We first find `116 Parse Predicate` for Loop Predicates, then `84 Parse
> Predicate` for Profiled Loop Predicates and then stop when finding `71
> Parse Predicate` for Loop Predicates because we've already found a Parse
> Predicate for Loop Predicates already. We then wrongly create Loop
> Predicates (above `116 Parse Predicate`) which are below newly created
> Profiled Loop Predicates (above `84 Parse Predicate`). This could lead to a
> bad graph because of data dependencies that rely on the fact that Loop
> Predicates are above Profiled Loop Predicates:
>
> https://github.com/openjdk/jdk/blob/547a8b40b324917e66c71409b31421feacce79d7/src/hotspot/share/opto/loopPredicate.cpp#L1529-L1543
>
> The fix is straight forward to make the assignment of Parse Predicate
> projections in `ParsePredicates` aware of the relative ordering constraint.
> Note that this class will be refactored again in [JDK-8305636](
> https://bugs.openjdk.org/browse/JDK-8305636). But I think properly fixing
> this first is better than waiting for JDK-8305636 to go in.
>
> Thanks,
> Christian
>
> -------------
>
> Commit messages:
> - 8308892: Bad graph detected in build_loop_late after JDK-8305635
>
> Changes: https://git.openjdk.org/jdk/pull/14196/files
> Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14196&range=00
> Issue: https://bugs.openjdk.org/browse/JDK-8308892
> Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod
> Patch: https://git.openjdk.org/jdk/pull/14196.diff
> Fetch: git fetch https://git.openjdk.org/jdk.git
> pull/14196/head:pull/14196
>
> PR: https://git.openjdk.org/jdk/pull/14196
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 29 May 2023 00:55:42 GMT
> From: Dingli Zhang <dzhang at openjdk.org>
> To: <hotspot-compiler-dev at openjdk.org>
> Subject: Re: RFR: 8308915: RISC-V: Improve temporary vector register
> usage avoiding the use of v0 [v2]
> Message-ID:
> <B3UopfF-5JbpYRVNRTbLkYWPlyzMQ1tDGYfaEax8MYA=.
> 907e2247-489d-4081-af8b-b138350dfe7a at github.com>
>
> Content-Type: text/plain; charset=utf-8
>
> > We have some macro assembler functions that use v0 hardcoded as a
> temporary
> > register currently.
> >
> > However, the mask value used to control execution of a masked vector
> > instruction is always supplied by vector register v0 in RVV1.0[1]. If v0
> is
> > alive holding a mask value the the same time, this will cause spilling
> of
> > this vector register. So it is better to replace v0 with other vector
> registers to
> > improve code execution efficiency.
> >
> > In addition, this pr also adds several missing spaces in the format of
> the
> > instructions, and fixes several pipeline classes.
> >
> > [1] https://github.com/riscv/riscv-v-spec/blob/v1.0/v-spec.adoc
> >
> > ## Testing:
> > QEMU w/ UseRVV:
> > - [x] Tier1 tests (release)
> > - [x] Tier2 tests (release)
> > - [x] Tier3 tests (release)
> > - [x] test/jdk/jdk/incubator/vector (fastdebug)
>
> Dingli Zhang has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Fix comment
>
> -------------
>
> Changes:
> - all: https://git.openjdk.org/jdk/pull/14166/files
> - new: https://git.openjdk.org/jdk/pull/14166/files/05446b0a..9fea08dc
>
> Webrevs:
> - full: https://webrevs.openjdk.org/?repo=jdk&pr=14166&range=01
> - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14166&range=00-01
>
> Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
> Patch: https://git.openjdk.org/jdk/pull/14166.diff
> Fetch: git fetch https://git.openjdk.org/jdk.git
> pull/14166/head:pull/14166
>
> PR: https://git.openjdk.org/jdk/pull/14166
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 29 May 2023 01:01:02 GMT
> From: Dingli Zhang <dzhang at openjdk.org>
> To: <hotspot-compiler-dev at openjdk.org>
> Subject: Re: RFR: 8308915: RISC-V: Improve temporary vector register
> usage avoiding the use of v0 [v2]
> Message-ID:
> <xMXJuW1gz2StrqaVlpEkijG9HiTb0VOIcMhfvo6oKuQ=.
> 9e998047-1019-4ac9-ac6c-22bef573048f at github.com>
>
> Content-Type: text/plain; charset=utf-8
>
> On Fri, 26 May 2023 09:41:19 GMT, Fei Yang <fyang at openjdk.org> wrote:
>
> >> Dingli Zhang has updated the pull request incrementally with one
> additional commit since the last revision:
> >>
> >> Fix comment
> >
> > Marked as reviewed by fyang (Reviewer).
>
> @RealFYang @yhzhu20 Thanks for the review!
>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/14166#issuecomment-1566339436
>
>
> End of hotspot-compiler-dev Digest, Vol 192, Issue 196
> ******************************************************
>
--
张力
一切有为法，当做如是观！
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-compiler-dev/attachments/20230529/148ea8df/attachment-0001.htm>
More information about the hotspot-compiler-dev
mailing list