[code-reflection] RFR: Bytecode round 12 [v3]
Paul Sandoz
psandoz at openjdk.org
Wed Sep 4 15:24:43 UTC 2024
On Wed, 4 Sep 2024 06:35:04 GMT, Adam Sotona <asotona at openjdk.org> wrote:
>> I still don't understand why the second check is needed, traversing the predecessors of `n`'s declaring block. If `n` is not dominated by any values in set `doms` then presumably such traversal has to encounter the entry block?
>>
>> The implementation of `Value::isDominatedBy` defers to block domination:
>>
>> public boolean isDominatedBy(Value dom) {
>> if (this == dom) {
>> return true;
>> }
>>
>> if (declaringBlock() != dom.declaringBlock()) {
>> return declaringBlock().isDominatedBy(dom.declaringBlock());
>> }
>> ...
>
> Individual dominations are handled as you describe. It applies for cases like this:
>
> entry -> var -> var store -> var load
> \
> > var store -> var load
>
>
> However following case needs a test for dominant set:
>
> entry -> var -> var store -> var load
> \ /
> > var store
>
> The var load is not dominated by any individual var store, however it is dominated by them.
>
> The test should fail for example on following case:
>
> entry -> var -> var store -> var load
> \ /
> ---------
>
>
> The reason why the second part is focused on blocks only is because ops cannot form a bypass inside one block.
Thanks! Doh, of course, i get it now. I think what you are doing is the equivalent of DA analysis. Perhaps we can rename the method accordingly? e.g., `isDefinitelyAssigned` (noting it does not distinguish between assignment with a default value or non-assignment in source because we don't currently make that distinction in the model).
What does the bytecode verifier do when it encounters bytecode in the last case? I expect the verifier will be enhanced to support the new object initialization protocol.
-------------
PR Review Comment: https://git.openjdk.org/babylon/pull/219#discussion_r1743998501
More information about the babylon-dev
mailing list