Hi,
On Tue, Dec 16 2025, Richard Biener wrote:
> On Mon, Dec 15, 2025 at 9:42 PM Martin Uecker <[email protected]> wrote:
>>
>> Am Montag, dem 15.12.2025 um 14:00 +0100 schrieb Richard Biener:
>> > On Sun, Dec 14, 2025 at 3:33 PM Martin Uecker via Gcc <[email protected]>
>> > wrote:
>> > >
>> > > Am Sonntag, dem 14.12.2025 um 15:10 +0100 schrieb Andreas Schwab:
>> > > > On Dez 14 2025, Martin Uecker via Gcc wrote:
>> > > >
>> > > > > One could use templates in C++ or macros, but then this is
>> > > > > rather heavy weight and also rigid as one has to structure the
>> > > > > code around it. I am rather looking for some lightweight
>> > > > > solution such as annotation I could put on the argument or variable
>> > > > > that says: If this is value is known to be a compile-time
>> > > > > constant, please create a specialized code path when optimizing.
>> > > > > (maybe with some limit on recursion), maybe only for specified
>> > > > > parameter ranges.
>> > > > >
>> > > > > Or are there other better ways to do this already?
>> > > >
>> > > > Is __builtin_constant_p what you are looking for?
>> > >
>> > > Not really. I know I can use it in some inline wrapper to
>> > > add my own compile-time specialization, but I want the compiler
>> > > to create the specialized code for me without having to duplicate
>> > > it the source. It can specialize code already just fine if it
>> > > likes to do so, but there seems to be no good way to
>> > > enforce this.
>> >
>> > It only specializes at calls with constant arguments. And it will not
>> > replace calls to with non-constant arguments with if (val == constant)
>> > specialization(); else regular();
>> > either. IIRC at some point we've talked about collecting
>> > "interesting" constants and directing
>> > all calls to a dispatcher. There might be a PR about this.
>> >
>> > So, do you actually want to have the unspecialized function replaced by
>> > a dispatcher that has a few values specialized?
>>
>> I am not 100% sure myself what I want/need, but something like a
>> dispatcher based on some manually specified constants is indeed
>> what I had in mind, e.g.
>>
>> int foo(int n)
>> [[gnu::specialize(0)]]
>> {
>> ...
>> }
>>
>> or maybe even inside functions
>>
>> int foo(int n)
>> {
>> ...
>> [[gnu::specialize(n == 3)]];
>> ...
>> }
>
> OK, so apart from this particular transform not being available
> (but all building blocks are) this sounds like a user-hint for
> interesting (common?) constants to specialize for. I could
> imagine FDO could collect histograms of function arguments
> (in the callee) as well, we could see during fnsummary computation
> which of the common constants would be worth specializing for
> (like we value-profile divisions already). The above function
> attribute would then provide alternate input for the machinery.
>
So far our speculative edges always create comparison of the target
address (whether it equals the function we think it is), we do not emit
comparisons of values of parameters (yet). All the other building
blocks are indeed there, I think.
...which is still something that needs to be clarified, we do want to
have these run-time checks right? Because earlier in the thread the
proposal looked as if we wanted to clone whenever we know the constant
is there but only if we know at compile time it is there. (That would
be really easy to implement because we would really have everything in
place).
Also, if we want the run-time checks, how do you want indirect calls to
behave?
> We also have value-ranges as IPA inputs, so even
> [[gnu::specialize(n < 5)]] might make sense?
We could do that too. At least currently for the parameters themselves,
we do not track value ranges for parts of aggregate parameters.
>
> I do like the ability to use assume-like expressions, but it might be
> a bit awkward to translate this into useful info. Can such attribute
> placement be restricted to be before any in-function mention of the
> arguments to avoid like
>
> int foo(int n)
> {
> n++;
> [[gnu::specialize(n == 3)]];
> }
>
> ?
>
> Can you open a PR for this?
Please CC mee too, thanks.
Martin
