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)