Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGWvnykYbN-OyJOkn8=eKFvuxAnMXQM01Us9iWOHy6w86_JM8w@mail.gmail.com>
Date: Tue, 20 Jun 2017 23:34:55 -0400
From: David Edelsohn <dje.gcc@...il.com>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] s390x: Add single instruction math functions

__ARCH__ = 9 for z196.

Attached is the original patch to add the FP math instructions and a
second patch using the test proposed by my colleague and following the
template of arm/sqrt.c to include the generic C code for earlier
architectures.

Thanks, David

On Tue, Jun 20, 2017 at 9:20 PM, Rich Felker <dalias@...c.org> wrote:
> On Tue, Jun 20, 2017 at 09:07:08PM -0400, David Edelsohn wrote:
>> Rich,
>>
>> Another option is a test recommended by a colleague
>>
>> #if (__HTM__ || __ARCH__ > z196)
>>
>> __HTM__ is defined in earlier releases of GCC and is enabled in zEC12,
>> so it can be used as a proxy for the architecture in earlier compiler
>> releases.
>>
>> Would that be acceptable?
>
> Indeed, __HTM__ gets defined for me on gcc 6.3 with -march=zEC12 but
> not with -march=z196. If that's acceptable to you I think it's okay;
> users could also build with "-march=z196 -D__ARCH__=???"  to get the
> math insns on baseline z196. BTW what is the actual value for __ARCH__
> indicating z196? I think I figured it out from the gcc source as 10.
> The "z196" you used in the above example isn't really a macro, is it?
> If so that's a bad namespace violation in gcc that needs to be
> fixed...
>
> Rich
>
>
>> On Tue, Jun 20, 2017 at 8:49 PM, Rich Felker <dalias@...c.org> wrote:
>> > On Sun, Jun 18, 2017 at 01:12:15PM -0400, David Edelsohn wrote:
>> >> How can we move forward with this patch?
>> >>
>> >> I would prefer to avoid the __ARCH__ complexity until there is a clear
>> >> user requirement.
>> >>
>> >> Thanks, David
>> >
>> > Rob Landley informed me that the s390x environment he's building with
>> > mkroot (https://github.com/landley/mkroot) for testing under qemu
>> > system level emulation is running a kernel built for z900. If qemu can
>> > emulate newer machines, this may just be an oversight that can be
>> > changes by reconfiguring, but it does indicate that z900 seems to be
>> > supported by kernel, and that there's at least someone using the
>> > baseline ISA level now.
>> >
>> > For what it's worth I agree that we've spent an inordinate amount of
>> > time on this topic, and I apologize. I just don't want it to turn into
>> > a regression.
>> >
>> > Rich
>> >
>> >
>> >> On Wed, Jun 14, 2017 at 7:44 PM, Rich Felker <dalias@...c.org> wrote:
>> >> > On Mon, Jun 12, 2017 at 09:28:52AM -0400, David Edelsohn wrote:
>> >> >> >> The following IBM table of supported and tested systems
>> >> >> >>
>> >> >> >> https://www-03.ibm.com/systems/z/os/linux/resources/testedplatforms.html
>> >> >> >>
>> >> >> >> shows that RHEL 7 and SLES 12 require at least z196, and Ubuntu 16.04
>> >> >> >> requires at least zEC12.
>> >> >> >>
>> >> >> >> I can't find any official hardware requirements description for Alpine
>> >> >> >> Linux. I tend to doubt that user would run it on older hardware,
>> >> >> >> especially hardware no longer supported by other, modern Linux
>> >> >> >> distributions.
>> >> >> >>
>> >> >> >> Building musl libc on older hardware is a nice accomplishment, but
>> >> >> >> investing effort and complexity to maintain support probably isn't
>> >> >> >> useful to any musl libc user and probably isn't a productive use of
>> >> >> >> developer resources.
>> >> >> >>
>> >> >> >> I will continue to inquire if there is a simple technique to accomplish this.
>> >> >>
>> >> >> Apparently GCC 7.1 added architecture macros.
>> >> >>
>> >> >> As Tuan referenced, Alpine Linux also requires z196 as the minimum
>> >> >> architecture level.  I believe that it would be better for s390-musl
>> >> >> to default to z196 ISA than musl to require GCC 7.1.
>> >> >
>> >> > I agree we shouldn't "require GCC 7.1", but using the macros does not
>> >> > imply such a requirement. For example:
>> >> >
>> >> >         #if __ARCH__ >= 10
>> >> >
>> >> > would only use the asm on z196+ (if I got the number right) with GCC
>> >> > 7.1+ (no asm on older compilers), whereas:
>> >> >
>> >> >         #if __ARCH__ >= 10 || !defined(__ARCH__)
>> >> >
>> >> > would use the asm on z196+ or on compilers too old to provide __ARCH__
>> >> > (and building for a more minimal baseline ISA would not be supported
>> >> > on such compilers unless you manually add -D__ARCH__=5 or whatever to
>> >> > CFLAGS).
>> >> >
>> >> > I'm fine with waiting to add those pp conditionals until if/when
>> >> > someone actually wants to use the lower baseline ISA, if you don't
>> >> > want to do it now. I am hesitant to add new ISA-forcing logic to
>> >> > configure, though (see the other reply on that). Would it be bad to
>> >> > have the build fail with low default -march? If so, maybe the
>> >> > configure logic could check for !defined(__ARCH__) and then do a
>> >> > compile test to define __ARCH__ on its own, and we could use the above
>> >> > logic?
>> >> >
>> >> > Rich

Download attachment "0001-Add-single-instruction-s390x-math-functions.patch" of type "application/octet-stream" (9121 bytes)

Download attachment "0002-Add-support-for-pre-z196-architecture.patch" of type "application/octet-stream" (10236 bytes)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.