RFR: 8338197: [ubsan] ad_x86.hpp:6417:11: runtime error: shift exponent 100 is too large for 32-bit type 'unsigned int' [v6]

[Andrew Dinn]

On Wed, 1 Oct 2025 02:11:31 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Boris Ulasevich has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains three commits:
>> 
>>  - use uint32_t for _mask
>>  - remove redundant code
>>  - 8338197: ubsan: ad_x86.hpp:6417:11: runtime error: shift exponent 100 is too large for 32-bit type 'unsigned int'
>
> My understanding is that pipeline latencies and instruction cost "latencies" are two different things, and only the latter affect matching/selection.  If OptoScheduling is turned off, pipeline scheduling should be turned off, but we will still get correct instruction selection based on "ins_cost", not "fixed_latency" or "pipe_class".

@dean-long 
> My understanding is that pipeline latencies and instruction cost "latencies" are two different things, and only the latter affect matching/selection. If OptoScheduling is turned off, pipeline scheduling should be turned off, but we will still get correct instruction selection based on "ins_cost", not "fixed_latency" or "pipe_class".

Doh! Of course, you are right. I  was mistaken in believing that 'ins_cost' was used to derive 'fixed_latency' for the mach node. It seems that it is inherited from the pipeline class declared in the instruction.

So, capping and/or tweaking the latencies will be neutral as far as instruction selection is concerned and, given the way the masking works, will be unlikely even to change scheduling.

We should still look at whether the pipeline model is actually benefiting us when it comes to scheduling and either modify it or, as a minimum, adjust the inappropriately high latencies encoded by some arches while ensuring this has no detrimental effect on code scheduling. I will update the description in https://bugs.openjdk.org/browse/JDK-8368971 to reflect your observation above.

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

PR Comment: https://git.openjdk.org/jdk/pull/26890#issuecomment-3355512594