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