RFR: 8345287: C2: live in computation is broken
Roland Westrelin
roland at openjdk.org
Thu Dec 5 08:16:37 UTC 2024
On Mon, 2 Dec 2024 14:04:30 GMT, Roland Westrelin <roland at openjdk.org> wrote:
>>> > Good catch! Do you have an example where the final schedule is affected by this issue?
>>>
>>> I don't. I noticed that live in sets are always empty while looking at memory usage of some `IndexSet`. It is puzzling that this didn't cause any performance regression. So it may be worth exploring why.
>>
>> OK, thanks. I will start by running some benchmarks on x64 with and without this fix. Will report results in a couple of days.
>
>> OK, thanks. I will start by running some benchmarks on x64 with and without this fix. Will report results in a couple of days.
>
> Sounds good. Thanks. If there happen to be a regression, I think it would make more sense to fix the code (with this patch) and disable `OptoRegScheduling` (until someone figures out what's going on) than keep code that doesn't make any sense.
> Given these results, I think it might be good to investigate what is the overall effect of `OptoRegScheduling` and whether it makes sense to keep it enabled for x64 before integrating this fix. The opposite order (integrating and then investigating how to deal with the regressions) seems like a higher-risk approach. @rwestrel @vnkozlov @dean-long what do you think?
What happens to the regresions with `OptoRegScheduling` turned off?
It may take a while to investigate the regressions. I wouldn't delay this fix to obviously very broken code until then if possible. So maybe wait for the fork, push this fix and then create a PR to disable `OptoRegScheduling`?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/22473#issuecomment-2519535158
More information about the hotspot-compiler-dev
mailing list