On Thu, 13 Mar 2025, Tejas Belagod wrote:
> On 3/13/25 1:28 PM, Richard Biener wrote:
> > 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?
> >
>
> Yes the GENERIC is in a partially transformed state and later 'fixed-up' in
> gimple which I was very uncomfortable about indeed.
>
> >> }
> >>
> >> 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?
> AFAICS, the subscript is transformed quite early into an
>
> ARRAY_REF (VIEW_CONVERT (vector))
>
> as a part of parsing C postfix expression. (Am I looking in the right
place?)
I think this is done by convert_vector_to_array_for_subscript in
c-common/, note that this handles lvalue conversion as well which
means it will not work in lvalue context where you'd possibly want
sth like a
TARGET_EXPR <D.1234, .VEC_CONVERT (vector)>
but then the caller needs to assign D.1234 to 'vector' with a
conversion back. This is going to be a bit difficult to deal
with given the parser structure.
Indexing bit-precision mask vectors really breaks the assumption
of convert_vector_to_array_for_subscript that there is an array
type that is layout-compatible to the vector. So we'd need to
handle this situation upthread somehow. The "cheap" way out
would be to use .VEC_SET and .VEC_EXTRACT temporarily (expansion
relies on the optabs to be presnet) and gimplify those away.
> Thanks,
> Tejas.
>
>
> >
> > 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)
