This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH RFC] add generic expansion for MULT_HIGHPART_EXP

On Wed, Aug 29, 2018 at 4:00 PM Alexander Monakov <> 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.


> > 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?


> Thanks.
> Alexander

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]