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