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.
We also have value-ranges as IPA inputs, so even
[[gnu::specialize(n < 5)]] might make sense?
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?
Richard.
>
> Martin
>
>
