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