Re: [RFC][mid-end] Support vectorization of complex numbers using machine instructions.
Tamar Christina writes: >> > so I'd need 5 parameters and then I'm guessing the other expressions >> would be removed by DCE at some point? >> >> Are you planning to make the FCMLA behaviour directly available as an >> internal function or provide a higher-level one that does a full complex >> multiply, with the target lowering that into individual instructions where >> necessary? > > I was planning on doing it as one internal function and leave it up to > the target to expand it however it needs to. OK, sounds good. >> What to do with the intermediate results you don't need is an interesting >> question :-). Like you say, I was hoping DCE would get rid of them later. >> Does that not work? > > I haven't tried it yet 😊 But I assume it'll work too. I have complex > add almost working, it generates the right code for the vectorized > loop. The loads are also corrected and the permute is gone and I > update all the data references for the two statements I replaced. Not sure what you mean by the last bit. Why do you need to replace data references rather than just use the existing ones? > However for the scalar tail loop I have a problem since I only have > vector versions of the instructions, and the scalar loop is created > from the same SLP tree. So I end up with the builtins in the tail > loop with nothing to expand them to and with no way to differentiate > between the two calls to the internal fn. > > I would need to somehow undo this for the scalar part.. The epilogue loop should just be a copy of the basic block before vectorisation is applied. The new calls shouldn't be in that, just in the SLP tree. (This is how pattern statements work too: they're never added to the basic block, they're just temporary statements attached to internal vectoriser structures.) Thanks, Richard
GCC 6.5 Release Candidate available from gcc.gnu.org
The first release candidate for GCC 6.5 is available from https://gcc.gnu.org/pub/gcc/snapshots/6.5.0-RC-20181019/ ftp://gcc.gnu.org/pub/gcc/snapshots/6.5.0-RC-20181019/ and shortly its mirrors. It has been generated from SVN revision 265300. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 6.5 on Friday, October 26th.
GCC 6.5 Status Report (2018-10-19)
Status == The 6.5 branch is now frozen for the final GCC 6.5 release, the release candidate has been announced. All changes to the branch require RM approval. Quality Data Priority # Change from last report --- --- P10 P2 199 - 11 P3 27 - 1 P4 128 - 2 P5 28 --- --- Total P1-P3 226 - 12 Total 384 - 14 Previous Report === https://gcc.gnu.org/ml/gcc/2018-10/msg00113.html
Should PHI result and arg types match?
Howdy! Are the types for PHI arguments and the corresponding result supposed to match? In the backwards threader I'm seeing: _103 = PHI <_173(11), 0B(12)> Where the type of _103 is cgraph_node *, and the type of _173 is symtab_node *. I know one is derived from the other (struct cgraph_node : public symtab_node), but I would have expected a cast somewhere. : # _173 = PHI <0B(6), _172(9)> if (_173 != 0B) goto ; [70.00%] else goto ; [30.00%] : _109 = _173->type; if (_109 == 1) goto ; [34.00%] else goto ; [66.00%] : # _103 = PHI <_173(11), 0B(12)> if (_103 != 0B) Similarly for simpler stuff. Is this legal?: typedef unsigned int UDItype __attribute__ ((mode (DI))); typedef UDItype UINT64; UINT64 c_prov_hi; long unsigned int z$w$5; ... # c_prov_hi_222 = PHI Thanks. Aldy
Re: Should PHI result and arg types match?
On Fri, Oct 19, 2018 at 12:47:00PM -0400, Aldy Hernandez wrote: > Howdy! > > Are the types for PHI arguments and the corresponding result supposed to > match? Like with most other gimple stmts, they need to satisfy useless_type_conversion_p (TREE_TYPE (phiresult), TREE_TYPE (phiarg)) for all args. And, most pointer conversions are considered useless, exceptions are if different address spaces are involved or conversions from function/method pointers to other pointers or vice versa, or if the pointers have different modes. Jakub
Re: Should PHI result and arg types match?
On 10/19/18 1:00 PM, Jakub Jelinek wrote: On Fri, Oct 19, 2018 at 12:47:00PM -0400, Aldy Hernandez wrote: Howdy! Are the types for PHI arguments and the corresponding result supposed to match? Like with most other gimple stmts, they need to satisfy useless_type_conversion_p (TREE_TYPE (phiresult), TREE_TYPE (phiarg)) for all args. And, most pointer conversions are considered useless, exceptions are if different address spaces are involved or conversions from function/method pointers to other pointers or vice versa, or if the pointers have different modes. Ah, that makes sense. Thanks! Aldy
Re: GCC 6.5 Release Candidate available from gcc.gnu.org
On 10/19/18 04:49, Jakub Jelinek wrote: The first release candidate for GCC 6.5 is available from https://gcc.gnu.org/pub/gcc/snapshots/6.5.0-RC-20181019/ ftp://gcc.gnu.org/pub/gcc/snapshots/6.5.0-RC-20181019/ and shortly its mirrors. It has been generated from SVN revision 265300. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 6.5 on Friday, October 26th. I bootstrapped and tested on power 7, power 8, and power 9 both BE and LE and saw no unexpected issues. -- -Bill Seurer
gcc-8-20181019 is now available
Snapshot gcc-8-20181019 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/8-20181019/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch revision 265334 You'll find: gcc-8-20181019.tar.xzComplete GCC SHA256=ab261dbb5c3c82998e553ee2b0ec7868f3abfa99ae6f6773ba220870c6c0e756 SHA1=078266c9612898a125216862eb1f616dd8d48d20 Diffs from 8-20181012 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
