On Thu Jul 9, 2026 at 3:26 PM CEST, Richard Biener <[email protected]> wrote:
> On Thu, 9 Jul 2026, Michal Jireš wrote:
>
>>
>> On Thu Jul 9, 2026 at 2:45 PM CEST, Richard Biener <[email protected]> wrote:
>> > On Thu, 9 Jul 2026, Michal Jires wrote:
>> >
>> >> Cache partitioning asserts that {min,max}_partition_size parameter
>> >> cannot be 0 to prevent later divisions by zero. This is needlessly
>> >> strict, we can clamp the value to 1 to get reasonable/expected behavior.
>> >
>> > Can you instead add IntegerRage(1, 2147483647) to the params in
>> > param.opt?
>> >
>>
>> Both {min,max}_partition_size currently work with 0 with the default
>> balanced partitioning, and likely someone uses it.
>>
>> And both values make some sense:
>> min_partition_size=0 -> there is no minimal partition size
>> max_partition_size=0 -> put every function into its own partition
>>
>> Both seem to be an expected outcome of approaching/reaching 0.
>
> But the assert now triggers for all partitioning algorithms since
> you touch partitioner_base?
partitioner_base can be used for new partitionings, but partitioner_base
is currently used only for balanced partitioning.
> That said, I'm fine with changing
> the behavior of --param min_partition_size, the exteme you
> mention should be -flto-partition=max, the other (always use
> lto-partitions number of partitions if possible) isn't directly
> accessible.
Both can be achieved by specifying {min,max}_partition_size=1.
But I don't see what is the benefit of forbidding this seemingly
reasonable value.
>
> Btw, why does std::max (...) without the explicit type not work?
>
std::max needs both arguments to have the same type. I could use 1l or
1ll to specify the type, but both are not guaranteed to be int64_t.
