RFR: JDK-8315279: Factor 'basic_plus_adr' out of PhaseMacroExpand and delete make_load/store [v3]

Vladimir Ivanov vlivanov at openjdk.org
Thu Aug 31 17:06:04 UTC 2023


On Thu, 31 Aug 2023 16:42:12 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

>> src/hotspot/share/opto/addnode.hpp line 181:
>> 
>>> 179:   }
>>> 180: 
>>> 181:   static Node* make(PhaseIterGVN& igvn, Node* base, int offset) {
>> 
>> The overloads do look confusing now. When seeing a call to a factory method, I expect to see all inputs to be separately initialized. With `basic_plus_adr` the intention was clearer.
>> 
>> I'm not against the refactoring, but it feels like it moves the code in the wrong direction. The root problem is that we can't use `GraphKit `during macro expansion, so we duplicated functionality there over time. (`PhaseIdealLoop` is another victim.)
>> 
>> A better way would be to use `GraphKit` directly. And when we discussed it last time [1], Roland mentioned it was already implemented in Valhalla repo. 
>> 
>> [1] https://mail.openjdk.org/pipermail/hotspot-compiler-dev/2020-August/039612.html
>
>> I expect to see all inputs to be separately initialized.
> 
> I'm not sure what you mean by this part. Can you elaborate a little here?

static Node* make(PhaseIterGVN& igvn, Node* base, Node* ptr, Node* offset) {
    return igvn.register_new_node_with_optimizer(new AddPNode(base, ptr, offset));
  }

vs

  static Node* make(PhaseIterGVN& igvn, Node* base, int offset) {
    return (offset == 0) ? base : make(igvn, base, base, (Node*) igvn.makecon(offset));
  }


IMO latter case adds more confusion than improves readability. Why not  unconditionally call `AddPNode::make(base, base, offset)` instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15480#discussion_r1311936070


More information about the shenandoah-dev mailing list