On Thu, 13 Mar 2025, Tejas Belagod wrote:
> On 3/12/25 4:45 PM, Richard Biener wrote:
> > On Wed, 12 Mar 2025, Tejas Belagod wrote:
> >
> >> On 3/10/25 7:21 PM, Richard Biener wrote:
> >>> On Sat, 8 Mar 2025, Tejas Belagod wrote:
> >>>
> >>>> On 3/8/25 12:55 AM, Tejas Belagod wrote:
> >>>>> On 3/7/25 5:34 PM, Richard Biener wrote:
> >>>>>> On Fri, 7 Mar 2025, Tejas Belagod wrote:
> >>>>>>
> >>>>>>> On 3/7/25 4:38 PM, Richard Biener wrote:
> >>>>>>>> On Fri, 7 Mar 2025, Tejas Belagod wrote:
> >>>>>>>>
> >>>>>>>>> Given a vector mode and its corresponding element mode, this new new
> >>>>>>>>> language
> >>>>>>>>> hook returns a vector type that has properties of the vector mode
> >>>>>>>>> and
> >>>>>>>>> element
> >>>>>>>>> type of that of the element mode. For eg. on AArch64, given VNx16BI
> >>>>>>>>> and
> >>>>>>>>> QImode
> >>>>>>>>> it returns VNx16QI i.e. the wider mode to BImode that is an SVE
> >>>>>>>>> mode.
> >>>>>>>>
> >>>>>>>> What's the rationale for this to be a new frontend hook? It seems
> >>>>>>>> to be a composition of a target hook (related_mode) and a
> >>>>>>>> frontend hook (type_for_mode).
> >>>>>>>
> >>>>>>> I don't know this part of the FE very well, so pardon if its wrong way
> >>>>>>> to
> >>>>>>> do
> >>>>>>> it.
> >>>>>>>
> >>>>>>> I was trying to find a generic way to determine a wider vtype for a
> >>>>>>> given
> >>>>>>> vmode in a language-agnostic way. It looks like lang hooks are the
> >>>>>>> generic
> >>>>>>> way
> >>>>>>> for the mid-end to communicate to the FE to determine types the FE
> >>>>>>> seems
> >>>>>>> fit,
> >>>>>>> so I decided to make it a langhook.
> >>>>>>
> >>>>>> Who is supposed to call this hook and for what reason? Why would the
> >>>>>> frontend be involved here?
> >>>>>>
> >>>>>
> >>>>> Ah, sorry, I should've mentioned. This hook is called in Patch 4/6
> >>>>> during
> >>>>> gimplification (gimplify_compound_lval) that implements the subscript
> >>>>> operator for svbool_t - this hook returns a 'container' type for an
> >>>>> n-bit
> >>>>> boolean type which in this case is a byte vector for the 1- bit svbool_t
> >>>>> vector. I involve the FE here in the same principle as for eg.
> >>>>> TYPE_FOR_SIZE
> >>>>> as the FE is best-placed to return the right 'container' type as defined
> >>>>> by
> >>>>> the language. The type returned by the FE is used to unpack svbool_t to
> >>>>> its
> >>>>> container vector type to implement the subscript operator.
> >>>>>
> >>>>>>> And how can it survive without
> >>>>>>>> a default implementation?
> >>>>>>>>
> >>>>>>>
> >>>>>>> I saw a comment in langhooks-def.h that says:
> >>>>>>>
> >>>>>>> /* Types hooks. There are no reasonable defaults for most of them,
> >>>>>>> so we create a compile-time error instead. */
> >>>>>>>
> >>>>>>> So I assumed it was OK to have a NULL default which presumably fails
> >>>>>>> at
> >>>>>>> build
> >>>>>>> time when a hook is not defined for a language. Is there a more
> >>>>>>> graceful
> >>>>>>> way
> >>>>>>> to remedy this?
> >>>>>>
> >>>>>> Well, you made the default a NULL pointer - what do you do at the use
> >>>>>> point of the hook when it's not defined?
> >>>>>>
> >>>>>
> >>>>> True. I saw some of the other type hooks had NULL, so AIUI, I imagined
> >>>>> it
> >>>>> could be NULL and it would crash when used for a FE that didn't
> >>>>> implement
> >>>>> it. I admit I'm not even sure if this is the right way to do this.
> >>>>>
> >>>>> So, before I embarked on a 'default' implementation (which I'm not fully
> >>>>> sure how to do) my main intention was to clarify (via this RFC) if the
> >>>>> langhook approach was indeed the best way for gimple to obtain the
> >>>>> related
> >>>>> vtype it needed for the vbool type it was unpacking to do the subscript
> >>>>> operation on?
> >>>>>
> >>>>
> >>>> Thinking about this a bit more, I realize my mistake - I've made this a
> >>>> langhook only for the purpose of gimplify to communicate to the FE to
> >>>> call
> >>>> c_common_related_vtype_for_mode (). I think I need to go back to the
> >>>> drawing
> >>>> board on this one - I'm not so convinced now that this is actually
> >>>> serving
> >>>> a
> >>>> new langhook need.
> >>>>
> >>>> If this new 'hook' is just a wrapper for targetm.vectorize.related_mode
> >>>> ()
> >>>> and
> >>>> type_for_mode () I can probably just call them directly during gimplify
> >>>> or
> >>>> c-common.cc instead of inventing this new hook.
> >>>
> >>> That was my thinking. The alternative is to (pre-)gimplify this either
> >>> during genericization or in the already existing gimplify_expr
> >>> langhook. Or perform the "decay" as part of GENERIC building.
> >>>
> >>
> >> When I tried to decay svbool to char[] during genericization, it is quite
> >> straighforward for svbool[] reads, but for writes I need to introduce a
> >> temporary (because VEC_CONVERT IFN can't be an lvalue) and I don't know if
> >> Generic is too early to allow for introducing temporaries.
> >
> > You might be doing the lvalues wrong then?
>
> Perhaps.
>
> For _Bool b = int the
> > frontend converts the int to _Bool, it doesn't decay _Bool to a
> > int "lvalue". So I'd expect the frontend, for svbool b = x to
> > have the 'x' possibly decayed as char[] and a conversion
> > via VEC_CONVERT inserted?
> >
>
> IIUC, what you're saying is in a situation like:
>
> svbool_t foo (svbool_t p, int i)
> {
> p[i] = i;
> return p;
> }
>
> Instead of VEC_CONVERTing p[i], convert 'i' to _Bool?
>
> IIRC I ran into a problem where the ARRAY_REF of the LHS svbool transformed to
> a BIT_FIELD_REF and this didn't allow fields smaller than byte access or poly
> offsets. So I had to transform 'p' to char[] through VEC_CONVERT like so in
> convert_vector_to_array_for_subscript ()
>
> {
> VIEW_CONVERT_EXPR<signed char[0:POLY_INT_CST [15, 16]]>(p)[i] = (signed
> char) i;
but isn't this simply wrong since char[] isn't the same as svbool
layout-wise? (or is it?)
Trying to "fix this up" during gimplification sounds wrong - you
feed it invalid GENERIC then?
> }
>
> and subsequently:
>
> svbool_t foo (svbool_t p, int i)
> {
> vector([16,16]) signed char D.14000;
> svbool_t D.14001;
>
> p.0_2 = p;
> _1 = .VEC_CONVERT (p.0_2);
> D.14000 = _1;
> _5 = (signed char) i;
> VIEW_CONVERT_EXPR<signed char[0:POLY_INT_CST [15, 16]]>(D.14000)[i] =
> _5;
> _4 = D.14000;
> _3 = .VEC_CONVERT (_4);
> p = _3;
> D.14001 = p;
> return D.14001;
> }
>
> during gimplify_lval(). Can I do this extra step of
>
> _1 = VEC_CONVERT(p)
>
> in the FE during GENERICization?
>
> I hope I understood you correctly.
I think you need to maintain a "correct" IL from the start.
What does parsing produce as GENERIC AST?
Richard.
> Thanks,
> Tejas.
>
>
> >> If I leave the decay too late till gimplification of the base expression of
> >> svbool happens in gimplify_compound_lval (), it becomes a bit tedious to
> >> rewrite parent nodes while walking back up the tree from the base
> >> expression -
> >> hence the hybrid approach to decay.
> >>
> >> Do you think leaving the tree in a partially rewritten state until
> >> gimplification can cause consistency checks to fail?
> >>
> >> Thanks,
> >> Tejas.
> >>
> >>> Richard.
> >>>
> >>>> Thanks for your reviews - I think I might be able to drop this patch and
> >>>> merge
> >>>> the necessary parts into later ones in the series!
> >>>>
> >>>> Thanks,
> >>>> Tejas.
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
> >
>
>
--
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
