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