From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73687 invoked by alias); 26 Aug 2019 13:23:51 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 73678 invoked by uid 89); 26 Aug 2019 13:23:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:D8TpwU0, H*f:5xyfWgp X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 26 Aug 2019 13:23:48 +0000 X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 210BBADCC; Mon, 26 Aug 2019 13:23:46 +0000 (UTC) From: Martin Jambor To: Richard Sandiford Cc: Segher Boessenkool , Tejas Joshi , gcc@gcc.gnu.org, hubicka@ucw.cz, joseph@codesourcery.com Cc: Subject: Re: Expansion of narrowing math built-ins into power instructions In-Reply-To: References: <20190820134613.GR31406@gate.crashing.org> <20190820194154.GY31406@gate.crashing.org> <20190821182852.GG31406@gate.crashing.org> <20190821191722.GH31406@gate.crashing.org> <20190822062503.GI31406@gate.crashing.org> <20190822095620.GK31406@gate.crashing.org> User-Agent: Notmuch/0.29.1 (https://notmuchmail.org) Emacs/26.2 (x86_64-suse-linux-gnu) Date: Mon, 26 Aug 2019 13:23:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00217.txt.bz2 Hi, On Sat, Aug 24 2019, Richard Sandiford wrote: > Martin Jambor writes: ... >> >> 2. direct_internal_fn_supported_p on which replacement_internal_fn >> depends to expand built-ins as internal functions cannot handle >> conversion optabs... and narrowing is a kind of conversion and the >> optab is added as such with OPTAB_CD. >> >> Actually, the second statement is not entirely true because somehow it >> can handle optab while_ult which is a conversion optab but a) the way it >> is handled, if I can understand it at all, seems to be a big hack and >> would be even worse if we decided to copy that for all narrowing math >> functions > > Think "big hack" is a bit unfair. The way that the internal function > maps argument types to the optab modes, and the way it expands calls > into rtl, depends on the "optab type" argument (the final argument to > DEF_INTERNAL_OPTAB_FN). This is relatively flexible in that it can use > a single-mode "direct" optab or a dual-mode "conversion" optab, with the > modes coming from whichever arguments are appropriate. New optab types > can be added as needed. My apologies. I guess I should have been more careful with my choice of words when perhaps I did not understand all aspects but when I saw: #define direct_while_optab_supported_p convert_optab_supported_p (and when I saw expand_while_optab_fn defined normally while all(?) other were constructed in an elaborate macro), I thought that I did not want to replicate the mechanism, not for a number of functions. > > FWIW, several other DEF_INTERNAL_OPTAB_FNs are conversion optabs too > (e.g. IFN_LOAD_LANES, IFN_STORE_LANES, IFN_MASK_LOAD, etc.). > > But... > >> and b) it gets both modes from argument types whereas we need one from >> the result type and so we would have to rewrite >> replacement_internal_fn anyway. > > ...yeah, I agree this breaks the current model. The reason IFN_WHILE_ULT > doesn't rely on the return type is that if you have: > > _2 = .WHILE_ULT (_0, _1) // returning a vector of 4 booleans > _3 = .WHILE_ULT (_0, _1) // returning a vector of 8 booleans > > then the calls look equivalent. So instead we pass an extra argument > indicating the required boolean vector "shape". > > The same "problem" could in principle apply to FADD if we ever needed > to support double+double->_Float16 for example. Right. I hope not going through an internal function is acceptable. If not, we'll have to teach this builtin->internal_funcxtion->optab mechanism about conversions. Thanks, Martin > >> Therefore, at least for now (GSoC deadline is kind of looming), I >> decided that the best way forward would be to not rely on internal >> functions but plug into expand_builtin() and I wrote the following, >> lightly tested patch - which of course misses testcases and stuff - but >> I'd be curious about any feedback now anyway. When I proposed a very >> similar approach for the roundeven x86_64 expansion, Uros actually then >> opted for a solution based on internal functions, so I am curious >> whether there are simple alternatives I do not see. >> >> Tejas, of course cases for other fadd variants should at least be added >> to expand_builtin. >> >> Thanks, >> >> Martin >> >> >> 2019-08-23 Tejas Joshi >> Martin Jambor >> >> * builtins.c (expand_builtin_binary_conversion): New function. >> (expand_builtin): Call it. >> * config/rs6000/rs6000.md (unspec): Add UNSPEC_ADD_NARROWING. >> (add_truncdfsf3): New define_insn. >> * optabs.def (fadd_optab): New. >>