https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118012
--- Comment #22 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #20)
> (In reply to Georg-Johann Lay from comment #19)
> > Mow it seems we need even more hacks in the avr BE to work around that
> > insanity in match.pd: For the following test case
> >
> > __uint24 mul24 (__uint24 a, __uint24 b)
> > {
> > return a * b;
> > }
>
> Can you file that seperately? Because that is slightly differnet issue and
> gimple looks fine:
> __int24 unsigned _3;
> _3 = a_1(D) * b_2(D);
>
> I have not looked into why expand does not cause a libcall to __mulpsi3 yet
> though. Maybe I can look this weekend.
PR122505
My guess is the following:
In order to hack around PR118012, avr backend added mulsi3 insns even for
targets that don't have MUL. This is needed so that combiner insns will work
(which cannot be done for libcalls).
Then the middle-end wants to expand mulpsi3 for which there is no insn, and it
concludes that mulsi3 is cheap since it has an insn. The middle-end then takes
mulsi3 insn instead of invoking a libcall for mulpsi3.
Actually, adding a mulpsi3 insn for the case when MUL is not available seems to
work — at least for targets that pass the __mulpsi3 arguments all in registers.
(In reply to Richard Biener from comment #21)
> I would expect __mulpsi3 to not be a thing? Only di3 and si3 should be
> there from my expectation how libgcc is built.
To date, mulpsi3 insn is only available for the devices that have MUL. This is
needed for better code, e.g. insn combine pattern when some operand is
zero-extended etc. Apart from that, the call __mulpsi3 insn can model the
register footprint of __mulpsi3 (which is smaller than that of a vanilla
libcall).
As explained above, in order to hack around PR118012 a mulsi3 insn has been
added for the non-MUL case, and the middle-end thinks that mulsi3 insn is
cheaper than a mulpsi3 libcall.
Using availability of insns is a bad proxy for costs of operations. Just the
fact that an insn exists doesn't mean is is cheap. And the fact that an insn
doesn not exists doesn't mean a libcall is expensive and not wanted.
