gcc-6-20160131 is now available
Snapshot gcc-6-20160131 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160131/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 233023 You'll find: gcc-6-20160131.tar.bz2 Complete GCC MD5=d05c35aa67425ebf728137bbd390a49d SHA1=ea914b738c55944d4d8c40e4f842225024130f01 Diffs from 6-20160124 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 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.
Re: [RFC PR43721] Optimize a/b and a%b to single divmod call
On 01/29/2016 12:37 AM, Richard Biener wrote: To workaround this, I defined a new hook expand_divmod_libfunc, which targets must override for expanding call to target-specific dimovd. The "default" hook default_expand_divmod_libfunc() expands call to libgcc2.c:__udivmoddi4() since that's the only "generic" divmod available. Is this a reasonable approach ? Hum. How do they get to expand/generate it today? That said, I'm no expert in this area. A simpler solution may be to not do the transform if there is no instruction for divmod. Are we certain that the libcall is a win for any target? I would have expected a default of q = x / y r = x - (q * y) to be most efficient on modern machines. Even more so on targets like ARM that have multiply-and-subtract instructions. I suppose there's the case of the really tiny embedded chips that don't have multiply patterns either. So that this default expansion still results in multiple libcalls. I do like the transformation, because for machines that don't have a divmod instruction, being able to strength-reduce a mod operation to a multiply operation is a nice win. r~
Re: [RFC PR43721] Optimize a/b and a%b to single divmod call
On Sun, Jan 31, 2016 at 2:15 PM, Richard Henderson wrote: > On 01/29/2016 12:37 AM, Richard Biener wrote: >>> >>> To workaround this, I defined a new hook expand_divmod_libfunc, which >>> targets must override for expanding call to target-specific dimovd. >>> The "default" hook default_expand_divmod_libfunc() expands call to >>> libgcc2.c:__udivmoddi4() since that's the only "generic" divmod >>> available. >>> Is this a reasonable approach ? >> >> >> Hum. How do they get to expand/generate it today? That said, I'm >> no expert in this area. >> >> A simpler solution may be to not do the transform if there is no >> instruction for divmod. > > > Are we certain that the libcall is a win for any target? > > I would have expected a default of > > q = x / y > r = x - (q * y) > > to be most efficient on modern machines. Even more so on targets like ARM > that have multiply-and-subtract instructions. > > I suppose there's the case of the really tiny embedded chips that don't have > multiply patterns either. So that this default expansion still results in > multiple libcalls. > > I do like the transformation, because for machines that don't have a divmod > instruction, being able to strength-reduce a mod operation to a multiply > operation is a nice win. > > > r~
Re: [RFC PR43721] Optimize a/b and a%b to single divmod call
On Sun, Jan 31, 2016 at 8:43 PM, Jim Wilson wrote: >> Are we certain that the libcall is a win for any target? >> I would have expected a default of >> q = x / y >> r = x - (q * y) >> to be most efficient on modern machines. Even more so on targets like ARM >> that have multiply-and-subtract instructions. If there is a div insn, then yes, gcc will emit a div and a multiply. However, a div insn is a relatively recent addition to the 32-bit ARM architecture. Without the div insn, we get a div libcall and a mod libcall. That means two libcalls, both of which are likely implemented by calling the divmod libcall and returning the desired part of the result. One call to a divmod libcall is clearly more efficient than two calls to a divmod libcall. So that makes the transformation useful. Prathamesh's patch has a number of conditions required to trigger the optimization, such as a divmod insn, or a lack of a div insn and the presence of a divmod libcall. Jim
Re: [RFC PR43721] Optimize a/b and a%b to single divmod call
On Fri, Jan 29, 2016 at 12:09 AM, Richard Biener wrote: > I wonder if rather than introducing a target hook ports could use > a define_expand expanding to a libcall for this case? Of the two divmod libcall APIs, one requires a stack temporary, which would be awkward to allocate in a define_expand. Though we could have expand_twoval_binop implement the libgcc udivmoddi4 API which requires a stack temp, and then add an ARM divmod expander that implements the ARM API which has a double-wide result. That sounds like it could work. Jim
