This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 1/2] Auto-generate maybe_fold_and/or_comparisons from match.pd
- From: Richard Biener <rguenther at suse dot de>
- To: Martin Liška <mliska at suse dot cz>
- Cc: gcc-patches at gcc dot gnu dot org, Marc Glisse <marc dot glisse at inria dot fr>, Li Jia He <helijia at linux dot ibm dot com>, Andrew Pinski <pinskia at gmail dot com>, Jeff Law <law at redhat dot com>, Segher Boessenkool <segher at kernel dot crashing dot org>, wschmidt at linux dot ibm dot com, Martin Liska <mliska at suse dot de>
- Date: Mon, 9 Sep 2019 15:39:35 +0200 (CEST)
- Subject: Re: [PATCH 1/2] Auto-generate maybe_fold_and/or_comparisons from match.pd
- References: <1561615913-22109-1-git-send-email-helijia@linux.ibm.com> <6fb28248-5134-cec5-5045-45253e4d2eb0@redhat.com> <6d333ccf-9905-e929-c2dc-fc611ff929f1@linux.ibm.com> <CA+=Sn1mgUXkEBQTzp5Nv5gcANtpZeutisEtQbez_L7xgg39ppw@mail.gmail.com> <alpine.LSU.2.20.1907010920230.10704@zhemvz.fhfr.qr> <bc69c05f-d966-cab7-b79f-a188523f9258@linux.ibm.com> <alpine.LSU.2.20.1907021007050.2976@zhemvz.fhfr.qr> <alpine.LSU.2.20.1907021031040.2976@zhemvz.fhfr.qr> <845bc280-7bd6-509b-3830-4ebde50f1b20@linux.ibm.com> <nycvar.YFH.7.76.1909051446520.5566@zhemvz.fhfr.qr> <daa3c217-3bfc-086d-da27-175a63da2c59@suse.cz> <863e9c71-7639-eaf9-fa13-32515ce0452f@suse.cz> <alpine.DEB.2.21.1909091456370.20886@grove.saclay.inria.fr> <c10b5c4e-458d-f09e-15e1-214b1c07c55a@suse.cz>
On Mon, 9 Sep 2019, Martin Liška wrote:
> On 9/9/19 3:10 PM, Marc Glisse wrote:
> > On Mon, 9 Sep 2019, Martin Liška wrote:
> >
> >> I'm sending slightly updated version of the patch where we
> >> need to properly select type in maybe_fold_comparisons_from_match_pd
> >> function for the created SSA_NAMEs. We can be called for a VECTOR_TYPE
> >> and so that we can't return a boolean_type_node.
> >
> > + tree type = TREE_TYPE (op1a);
> > + if (TREE_CODE (type) != VECTOR_TYPE)
> > + type = boolean_type_node;
> >
> > Don't you need build_same_sized_truth_vector_type or something, for instance with AVX512?
> >
> > Also, IIRC EQ_EXPR for vectors can return either a vector or a boolean. I don't know if we can end up here with both versions, but if we can, guessing the type could be dangerous. Would it be hard to add a type argument to those functions and delegate this to the caller? Any better idea (maybe this is already safe and I am just missing it)?
>
> Richi can you help us here? I'm not sure what guarantees do we have here in GIMPLE?
Oops, I missed this hunk - the caller needs to pass this down, but at
least from the ifcombine use we are always coming from a if (a CMP b)
context and thus a boolean_type_node result type. For the reassoc
case there's indeed nothing preventing from vector typed comparisons
sneaking in here, likewise recursion via or_var_with_comparison_1
might run into vectors.
Thus the toplevel interface has to pass down the (common) type of
the two comparisons.
Richard.