On Tue, 28 Aug 2018, Richard Biener wrote: > I think that if we want to support MULT_HIGHPART generally then we need > to support it for all modes - what's your plan for 32bit targets here? This > means providing libgcc fallback implementations for modes we cannot directly > expand to.
I didn't have a plan in mind, but yes, it seems a fallback implementation would perform a widening multiplication in 4 or 3 (with Karatsuba's trick) widest multiplications and throw away the low half. Signed case may need more care, I'm not sure at the moment. > I'd also like to see better support for MULT_HIGHPART then, for example > verify_gimple_assign_binary does nothing (TODO). I realize I'm not aware of places that would need to be improved, but verify_gimple_assign_binary doesn't seem like one of them - as far as I see it treats MULT_HIGHPART exactly like MULT which looks alright. > As for the expansion code I wonder if handling it in expand_binop would > be better? No idea. > Do we want to expose highpart multiply to users somehow? Probably not. But there's another way to look at it: generic expansion for mul-highpart would open the way for efficient 64-bit division by constants on 32-bit platforms. Would you recommend BRIG FE to repair this on their end for now? I don't mind punting on my patch (but in that case please tell me if I should commit the gimplefe __MULT_HIGHPART anyway). Thanks. Alexander
