On Wed, 9 Sep 2026, Jeff Law wrote:
>
>
> On 9/9/26 6:03 AM, Richard Biener wrote:
> > The following exposes function pointer canonicalization for
> > comparisons early by lowering to an internal function call
> > during gimplification. This allows us to make conversions
> > to function pointers useless, restoring symmetry and
> > avoiding issues like PR127263.
> >
> > I have not removed gates on few optimizations.
> >
> > Function pointer canonicalizations for comparisons are only
> > required for 32bit hppa. I built a cc1 cross and verified
> > this works for gcc.dg/tree-ssa/pr22051-1.c but I have no
> > further means (or intent ...) of testing. Jeff, I suppose
> > you have some way of testing 32bit hppa for regressions?
> There's two platforms where this mattered.
>
> 32 bit SOM. I shut my last system down eons ago and never even tried to
> resurrect something on top of QEMU.
>
> 32 bit portable runtime. This may be used on the 32 bit Linux port. I don't
> really know as I've not been involved with that in any meaningful way. I do
> have this in my tester (and in fact will need to debug a regression soon), but
> the ABI details and such have long since been dropped from my memory.
>
> John David Anglin (on cc) may have more state. From a very quick review of
> the PA code, I think we need to use the function pointer canonicalization
> pattern for expansion rather than going straight to the canonicalization
> function. My PA ABI is very rusty, but it looks to be a bit nonstandard,
> closer to millicode patterns which use a different ABI than normal calls.
So for hppa-linux the gcc.dg/tree-ssa/pr22051-1.c compiles now to
foo:
.PROC
.CALLINFO FRAME=128,CALLS,SAVE_RP
.ENTRY
stw %r2,-20(%r30)
ldo 128(%r30),%r30
bl arf,%r2
nop
bl __canonicalize_funcptr_for_compare,%r2
copy %r28,%r26
ldw -148(%r30),%r2
comiclr,<> 0,%r28,%r28
ldi 1,%r28
ldo 1(%r28),%r28
bv %r0(%r2)
ldo -128(%r30),%r30
.EXIT
.PROCEND
which gemini analyzed to do the correct thing. Exposing this
earlier will for sure expose this to CSE, loop invariant hoisting,
etc. - but possibly also on RTL if it is a libcall (didn't check).
Richard.
