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