Hi!
On Thu, Aug 26, 2021 at 07:59:04AM -0500, Bill Schmidt wrote:
> On 8/25/21 6:27 PM, Segher Boessenkool wrote:
> >On Thu, Jul 29, 2021 at 08:31:01AM -0500, Bill Schmidt wrote:
> >> * config/rs6000/rs6000-overload.def: Add remaining overloads.
> >>+; TODO: Note that the entry for VEC_ADDE currently gets ignored in
> >>+; altivec_resolve_overloaded_builtin. Revisit whether we can remove
> >>+; that. We still need to register the legal builtin forms here.
> >>+[VEC_ADDE, vec_adde, __builtin_vec_adde]
> >>+ vsq __builtin_vec_adde (vsq, vsq, vsq);
> >>+ VADDEUQM VADDEUQM_VSQ
> >>+ vuq __builtin_vec_adde (vuq, vuq, vuq);
> >>+ VADDEUQM VADDEUQM_VUQ
> >I'm not sure what this means. "Currently" is the problem I think. Do
> >you mean that the existing code (before this patch) ignores it already?
>
> Right, exactly. There is special-case code there for handling ADDE
> builtins, as there is for a number of other cases. As a future cleanup,
> we'd like to have as little special-case code as possible. For this
> conversion effort, I elected to wait with that and leave the TODO here
> in the file.
Ah, so it means the same as s/currently gets/is/ :-)
It is fine to not shave this yak right now of course.
> >>+; Note that the entries for VEC_MUL are currently ignored. See
> >>rs6000-c.c:
> >>+; altivec_resolve_overloaded_builtin, where there is special-case code
> >>for
> >>+; VEC_MUL. TODO: Is this really necessary? Investigate. Seven missing
> >>+; prototypes here...no corresponding builtins. Also added "vmulld" in
> >>P10
> >>+; which could be used instead of MUL_V2DI, conditionally?
> >Space after "..." :-P
(Remember to fix this important problem! :-) )
> >>+; Opportunity for improvement: We can use XVRESP instead of VREFP for
> >>+; TARGET_VSX. We would need conditional dispatch to allow two
> >>possibilities.
> >>+; Some syntax like "XVRESP{TARGET_VSX};VREFP".
> >>+; TODO. ####
> >>+[VEC_RE, vec_re, __builtin_vec_re]
> >Don't we already anyway? The only difference is whether all VSRs are
> >allowed or only the VRs, no? The RTL generated is just the same? Or
> >maybe I am overlooking something :-)
>
> Right, this is the same conclusion I came to -- I should be able to just
> use vector.md pattern names. Future improvement (and maybe altogether
> unnecessary; I'll do some testing).
We still need to have both builtins, even if they do the same thing.
External names are forever and all that.
> >Okay for trunk with the #### looked at. Please don't repost this one.
> >Thanks!
>
> Awww. :-P
Hey there are 20 more patches in this series, you'll have plenty more
opportunity to torture me :-)
Segher
