This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH RFC] add generic expansion for MULT_HIGHPART_EXP
On Tue, Aug 28, 2018 at 7:59 AM Alexander Monakov <firstname.lastname@example.org> wrote:
> > > > So - how difficult is it to fix BRIG to not use MULT_HIGHPART_EXPR if
> > > > not supported?
> Richard, how should we proceed from here? Do you like the solution in the
> initial mail, or would you prefer something else? FWIW I agree with Pekka,
> no need to burden BRIG FE with expanding mul-highpart.
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
I'd also like to see better support for MULT_HIGHPART then, for example
verify_gimple_assign_binary does nothing (TODO).
As for the expansion code I wonder if handling it in expand_binop would
be better? Do we want to expose highpart multiply to users somehow?
> > > Pekka, can you comment? I think you have fallback paths for vector types
> > > only at the moment?
> > I think it involves pretty much moving the code of your patch to the
> > BRIG frontend.
> > To me it'd look a bit wrong in terms of "division of responsibilities"
> > as this is not really
> > frontend-specific as far as I understand (even if BRIG/HSAIL happened
> > to be the only language
> > supporting them currently).
> > > Does BRIG have mult-highpart for 64-bit integers? On 32-bit targets we
> > > won't be able to easily expand them (but on 64-bit targets it is fine).
> > Yes it does. 32b targets are not high priority for BRIG FE at this
> > point, so I wouldn't
> > worry about this as we assume HSA's "large" model is used, so this is likely not
> > the only problem when trying to generate for 32b machines.
> > > For scalar types I think we should prefer to implement a generic expansion
> > > rather than have the frontend query the backend. For vector types I am not
> > > sure.
> > In my relatively gcc-uneducated humble opinion these both belong more
> > naturally to a
> > target-specific expansion or "legalization" pass, which tries to
> > convert tree nodes to what the target
> > can support.
> > BR,
> > Pekka