On Sat, 22 Apr 2023 01:52:37 GMT, Vladimir Ivanov <[email protected]> wrote:
>> Cesar Soares Lucas has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains 10 commits:
>>
>> - Catching up with master
>>
>> Merge remote-tracking branch 'origin/master' into
>> rematerialization-of-merges
>> - Fix tests. Remember previous reducible Phis.
>> - Address PR review 3. Some comments and be able to abort compilation.
>> - Merge with Master
>> - Addressing PR review 2: refactor & reuse MacroExpand::scalar_replacement
>> method.
>> - Address PR feeedback 1: make ObjectMergeValue subclass of ObjectValue &
>> create new IR class to represent scalarized merges.
>> - Add support for SR'ing some inputs of merges used for field loads
>> - Fix some typos and do some small refactorings.
>> - Merge master
>> - Add support for rematerializing scalar replaced objects participating in
>> allocation merges
>
> src/hotspot/share/code/debugInfo.cpp line 257:
>
>> 255: } else {
>> 256: assert(selector < _possible_objects.length(), "sanity");
>> 257: _selected = (ObjectValue*) _possible_objects.at(selector);
>
> Any particular reason to reuse `ObjectValue` from `_possible_objects` instead
> of allocating a fresh one (as you do on `selector == -1` bracnh)? I'd prefer
> `ObjectMergeValue::select()` to always allocate a fresh `ObjectValue` when
> converting `ObjectMergeValue` + `ObjectMergeCandidateValue` into
> `ObjectValue`.
@iwanowww - may I ask why always allocating a fresh object might be better than
returning a pointer to a previous "selected" object?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/12897#discussion_r1175897406
