On Sat, Mar 30, 2019 at 10:30:23AM +, George Spelvin wrote:
> For s390, that was added on 24 March 2017 by
> https://gcc.gnu.org/viewcvs/gcc?view=revision=246457
> which is part of GCC 7.
>
> It also only applies to TARGET_ARCH12, which I am guessing
> corresponds to
On Sat, Mar 30, 2019 at 11:28:21AM +, George Spelvin wrote:
> >> I like that the MIPS code leaves the high half of the product in
> >> the hi register until it tests the low half; I wish PowerPC would
> >> similarly move the mulhdu *after* the loop,
>
> > The MIPS code has the multiplication
On Sat, Mar 30, 2019 at 09:00:15AM +1300, Michael Cree wrote:
> It does move the umulh inside the loop but that seems sensible since
> the use of unlikely() implies that the loop is unlikely to be taken
> so on average it would be a good bet to start the calculation of
> umulh earlier since it has
I've been tracking down when "umulditi3" support was added to various
gcc platforms. So far, I've found:
ia64: 2005-07-28, gcc 4.1.0
https://gcc.gnu.org/viewcvs/gcc?view=revision=102463
mips: 2008-06-09, gcc 4.4.0
https://gcc.gnu.org/viewcvs/gcc?view=revision=136600
alpha: 2013-02-01, gcc
General update:
I've since found the reason for the GCC version check.
It's not *broken* support (apologies for impugning GCC),
but *inefficient* support via a muditi3 helper function.
The version check is the version which added in-line code generation.
For example, s390 support was added in
On Sat, 30 Mar 2019 at 09:43:47 +0100, Heiko Carstens wrote:
> It hasn't been enabled on s390 simply because at least I wasn't aware
> of this config option. Feel free to send a patch, otherwise I will
> enable this. Whatever you prefer.
>
> Thanks for pointing this out!
Here's a draft patch,
On Fri, Mar 29, 2019 at 01:07:07PM +, George Spelvin wrote:
> (Cross-posted in case there are generic issues; please trim if
> discussion wanders into single-architecture details.)
>
> I was working on some scaling code that can benefit from 64x64->128-bit
> multiplies. GCC supports an
Hi!
On Fri, Mar 29, 2019 at 01:07:07PM +, George Spelvin wrote:
> I was working on some scaling code that can benefit from 64x64->128-bit
> multiplies. GCC supports an __int128 type on processors with hardware
> support (including z/Arch and MIPS64), but the support was broken on
> early
On Fri, Mar 29, 2019 at 01:07:07PM +, George Spelvin wrote:
> I was working on some scaling code that can benefit from 64x64->128-bit
> multiplies. GCC supports an __int128 type on processors with hardware
> support (including z/Arch and MIPS64), but the support was broken on
> early
(Cross-posted in case there are generic issues; please trim if
discussion wanders into single-architecture details.)
I was working on some scaling code that can benefit from 64x64->128-bit
multiplies. GCC supports an __int128 type on processors with hardware
support (including z/Arch and
10 matches
Mail list logo