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
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
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_divm
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-a
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
