RFR: 8304720: SuperWord::schedule should rebuild C2-graph from SuperWord dependency-graph [v2]
Emanuel Peter
epeter at openjdk.org
Fri May 5 09:00:02 UTC 2023
On Fri, 5 May 2023 07:56:29 GMT, Fei Gao <fgao at openjdk.org> wrote:
>> Thanks for the question. It is what I mentioned in the PR description:
>>
>>> This scheduling has the nice side-effect of simplifying SuperWord::output a little.
>> We know now that the first element in a pack is also first in the slice order, and the last element in the pack is last in the slice (because we schedule the packs as a block, i.e. in the pack order).
>>
>> **Details**
>> We add the pack to `memops_schedule`, in the order of the pack:
>> https://github.com/openjdk/jdk/blob/677400bbcd1921b280a63de2ce60aefa1c835241/src/hotspot/share/opto/superword.cpp#L2506-L2518
>>
>> And then we reorder all memops according to this schedule:
>> https://github.com/openjdk/jdk/blob/677400bbcd1921b280a63de2ce60aefa1c835241/src/hotspot/share/opto/superword.cpp#L2617-L2619
>
> Hi @eme64 thanks for your reply. Since all these nodes in a pack are executed at the same time, we don't really care about the first or last one, i.e., position in the pack. What we really care about is if we can get the right memory input from the first or last one for the pack, correctly connecting to other mem ops in the loop body. Did I get that right? Thanks.
@fg1417 Yes, that is the reason. This was like that before and after my patch.
I did not want to change too much here. I wanted to avoid refactoring the whole of `SuperWord::output`.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/13354#discussion_r1185854548
More information about the hotspot-compiler-dev
mailing list