RFR: 8304720: SuperWord::schedule should rebuild C2-graph from SuperWord dependency-graph [v2]

[Fei Gao]

On Fri, 5 May 2023 03:50:27 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> src/hotspot/share/opto/superword.cpp line 2768:
>> 
>>> 2766:     Node* n = _block.at(i); // last in pack
>>> 2767:     Node_List* p = my_pack(n);
>>> 2768:     if (p != nullptr && n == p->at(p->size()-1)) {
>> 
>> Sorry, I don't quite understand why the mem ops in the pack are internally in order. Maybe I missed somewhere you reordered these ops in the same pack using linearized memops_schedule. Could you please point it out for me? Thanks.
>
> 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.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13354#discussion_r1185801012