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