On Fri, May 24, 2024 at 12:20 PM Kewen.Lin <li...@linux.ibm.com> wrote:
>
> Hi Joseph and Richi,
>
> on 2024/5/13 21:18, Joseph Myers wrote:
> > On Mon, 13 May 2024, Kewen.Lin wrote:
> >
> >>> In fact replacing all of X_TYPE_SIZE with a single hook might be 
> >>> worthwhile
> >>> though this removes the "convenient" defaulting, requiring each target to
> >>> enumerate all standard C ABI type modes.  But that might be also a good 
> >>> thing.
> >>>
> >>
> >> I guess the main value by extending from floating point types to all is to
> >> unify them?  (Assuming that excepting for floating types the others would
> >> not have multiple possible representations like what we faces on 128bit 
> >> fp).
> >
> > For integer types, giving the number of bits makes sense as an interface -
> > there isn't an issue with different modes.
> >
> > So I think it's appropriate for floating and integer types to have
> > separate hooks - with the one for floating types returning a mode, and the
> > one for integer types returning a number of bits.  (And also keep the
> > existing separate hook for _FloatN / _FloatNx modes.)
> >
> > That may also make for more convenient defaults (whether a target has long
> > double wider than double is largely independent of what sizes it uses for
> > integer types).
> >
>
> Following your suggestion and comments, I made this patch
> for mode_for_floating_type first, considering this touches
> a few FE and port specific code, I think I have to split
> it into a patch series.  Before making that, I'd like to
> ensure this meets what you expected, and also seek for the
> suggestion on how to organize the sub-patches.  There seem
> two ways for sub-patches:
>   1) split this into pieces according to FEs and ports, and
>      squash all of them and commit one patch.
>   2) extract all hook implementation as 1st series (split
>      as ports);
>      extract the hook enablement as 2nd part (split as
>      generic and FEs);
>      the remaining is to remove useless macros (split it
>      as generic and ports);
>
> The 1) is straightforward, while the 2) is fine-grained and
> easy for isolation, but not sure if it's worth doing.
>
> btw, the attached patch is bootstrapped and regtested on
> powerpc64-linux-gnu and powerpc64le-linux-gnu with all
> languages on, cross cc1 built well for affected ports.

Looks reasonable to me - I'd split language changes out but
keep target and middle-end together.  The middle-end parts
look good to me - I'm always a bit nervous when using
size and precision exchangably, esp. for FP, but it seems
this has been done before.

I hope Joseph will eye that part as well.

Thanks for doing this,
Richard.

> BR,
> Kewen
>
> -----

Reply via email to