On Wed, Aug 29, 2018 at 4:00 PM Alexander Monakov <amona...@ispras.ru> wrote: > > 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.
OK. > > As for the expansion code I wonder if handling it in expand_binop would > > be better? > > No idea. At least there would be the code to try wider modes and the libcall fallback. > > 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. I see. But then when highpart multiply is not available as instruction probably not - and this should be already possible on RTL then. And on GIMPLE if it is available. > 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). The gimplefe __MULT_HIGHPART is useful so please go ahead with that. I'm not convinced there's a compelling reason to allow MULT_HIGHPART if it eventually expands to more than a single instruction. The reason we allow vector operations the HW doesn't understand is generic vector support in the frontends. So if we'd provide a generic highpart multiply intrinsic (ISTR other compilers have this) then this would make sense. So - instead of attacking this at RTL expansion stage or the BRIG FE side the option is to lower the code during vector lowering for example or during gimplification (just to name two passes where we generally perform lowering steps apart from RTL expansion). Do others have an opinion on how to handle this? Richard. > > Thanks. > Alexander
