[code-reflection] RFR: Bytecode round 12 [v3]
Adam Sotona
asotona at openjdk.org
Wed Sep 4 16:28:30 UTC 2024
On Wed, 4 Sep 2024 15:21:31 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:
>> 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.
Code with redundant default value assignment is valid, it just causes instability (the code grows with each round).
-------------
PR Review Comment: https://git.openjdk.org/babylon/pull/219#discussion_r1744092091
More information about the babylon-dev
mailing list