Re: GCC, OpenMP, -march=
The features in question are: 1) OpenMP with the GCC-port. It is disabled by default. Is there a reason for this? Are there any known "blockers"? Should I be able to make it work, would patches be accepted? There was a diff about half a year ago which added this. Some ports need adjustments because they pick up libgomp. I can dig up the old patches tomorrow ... That would be great, thank you! (Although I am not in hurry, won't work on this before the end of the week) 2) CPU-features like POPCNT, AVX are apparently not supported right now (or at least not with gcc). Also if you build software with the gcc-4.9-port and specify -march=native gcc wil produce code that actually uses instructions that are not supported, and then fail with messages like this: AVX should work (we also have the kernel support), popcnt does not. I don't know what it would take to add this to our copy of gas. Ah, thats interesting. I had thought that POPCNT being a part of SSE4 would be implemented before and hadn't checked for AVX. I will have a look... Also, I think it's generally a better idea to explicitly turn on the instruction sets you want/need rather than using -march=native. Yes and no. We ship binaries with -msse -msse2 -msse3 -mssse3 -msse4 -mpopcnt But I do recommend -march=native for people building themselves, because on Linux and FreeBSD it "just works" and produces measurably faster code even for our applications that are not manually tuned. I agree that it is not super-important, but on the other hand, POPCNT seems to be one of the few things missing to make -march=native work for a lot of older platforms so I think it's worth investigating. Thanks for the feedback, Hannes
Re: GCC, OpenMP, -march=
On 03/26/16 21:44, Stuart Henderson wrote: On 2016/03/26 20:13, Karel Gardas wrote: have you tried to bootstrap your own gcc with recent binutils? i.e. --with-as=... On the other hand you may also give a try to LLVM/clang from ports and see if they support your required features... OpenBSD binutils is modified for things like W^X. As far as i386 and amd64 go it's probably a more useful approach to write support for the additional opcodes, see the most recent couple of commits in src/gnu/usr.bin/binutils-2.17 for clues about how to do this. I will take a loot, thanks for the pointer. For some other arch (ARM in particular) support in binutils-2.17 is a bit of a stumbling point...not sure quite what to do there. Hm, I have no clue about ARM tobe honest.. Alternatively yes do try LLVM/Clang as that has its own assembler. Yep, I will look at it. Thanks, Hannes
Re: GCC, OpenMP, -march=
On 03/26/16 20:13, Karel Gardas wrote: have you tried to bootstrap your own gcc with recent binutils? i.e. --with-as=... I will take some time next weekend and try! On the other hand you may also give a try to LLVM/clang from ports and see if they support your required features... I will checkout llvm, although openmp has just recently been switched on in the default builds -- 3.8 more precisely which isn't in the ports, yet. Thanks for the feedback, Hannes
Re: GCC, OpenMP, -march=
On Sat, 26 Mar 2016 17:25:38 +0100, Hannes Hauswedell wrote: > Hi folks, > > I develop software for work that uses some advanced cpu features and > parallelism. While I fully understand that high-performance is not a > focus for OpenBSD, I would still like to be able to test basic stuff on > my Laptop (which happens to run OpenBSD). So, before I get my hands > dirty on this, I'd like to ask if there are structural issues and/or > policies preventing those features from working, or whether just no-one > was interested up until now (I have done some basic searching but didn't > come up with too much). > > The features in question are: > > 1) OpenMP with the GCC-port. It is disabled by default. Is there a > reason for this? Are there any known "blockers"? Should I be able to > make it work, would patches be accepted? There was a diff about half a year ago which added this. Some ports need adjustments because they pick up libgomp. I can dig up the old patches tomorrow ... > 2) CPU-features like POPCNT, AVX are apparently not supported right now > (or at least not with gcc). Also if you build software with the > gcc-4.9-port and specify -march=native gcc wil produce code that > actually uses instructions that are not supported, and then fail with > messages like this: AVX should work (we also have the kernel support), popcnt does not. I don't know what it would take to add this to our copy of gas. Also, I think it's generally a better idea to explicitly turn on the instruction sets you want/need rather than using -march=native. > /tmp//ccF2Aqg7.s: Assembler messages: > /tmp//ccF2Aqg7.s:1668791: Error: no such instruction: `popcntl > -4(%rbp),%eax' > /tmp//ccF2Aqg7.s:1669741: Error: no such instruction: `popcntq > -8(%rbp),%rax' > > -> Are there plans to support more modern CPU-extensions and is there a > list somewhere of which extensions are supported and which ones aren't? Nope, you'd have to go through the commit log of base binutils. > I guess they could be useful for other low-level stuff like encryption, > as well.. > --> If not, should the gcc-port be adapted to not offer those extensions > that aren't supported? That really only makes sense for automatic detection of CPU features (i.e. -march=native). That is obviously not used in ports, so it's not a high priority, although I would not be opposed to a patch. > Thanks and best regards, > Hannes > >
Re: GCC, OpenMP, -march=
On 2016/03/26 20:13, Karel Gardas wrote: > have you tried to bootstrap your own gcc with recent binutils? i.e. > --with-as=... On the other hand you may also > give a try to LLVM/clang from ports and see if they support your > required features... OpenBSD binutils is modified for things like W^X. As far as i386 and amd64 go it's probably a more useful approach to write support for the additional opcodes, see the most recent couple of commits in src/gnu/usr.bin/binutils-2.17 for clues about how to do this. For some other arch (ARM in particular) support in binutils-2.17 is a bit of a stumbling point...not sure quite what to do there. Alternatively yes do try LLVM/Clang as that has its own assembler. > > /tmp//ccF2Aqg7.s: Assembler messages: > > /tmp//ccF2Aqg7.s:1668791: Error: no such instruction: `popcntl > > -4(%rbp),%eax' > > /tmp//ccF2Aqg7.s:1669741: Error: no such instruction: `popcntq > > -8(%rbp),%rax' > > > > -> Are there plans to support more modern CPU-extensions and is there a list > > somewhere of which extensions are supported and which ones aren't? I guess > > they could be useful for other low-level stuff like encryption, as well.. There's no single list of all extensions supported. You can find the additions to binutils-2.17 by reading commit log, for example XSAVE, SMAP, RDRAND/RDSEED and the virtualization instructions were added. 2.17 already supported AESNI. > > --> If not, should the gcc-port be adapted to not offer those extensions > > that aren't supported? Yes.
Re: GCC, OpenMP, -march=
have you tried to bootstrap your own gcc with recent binutils? i.e. --with-as=... On the other hand you may also give a try to LLVM/clang from ports and see if they support your required features... On Sat, Mar 26, 2016 at 5:25 PM, Hannes Hauswedellwrote: > Hi folks, > > I develop software for work that uses some advanced cpu features and > parallelism. While I fully understand that high-performance is not a focus > for OpenBSD, I would still like to be able to test basic stuff on my Laptop > (which happens to run OpenBSD). So, before I get my hands dirty on this, I'd > like to ask if there are structural issues and/or policies preventing those > features from working, or whether just no-one was interested up until now (I > have done some basic searching but didn't come up with too much). > > The features in question are: > > 1) OpenMP with the GCC-port. It is disabled by default. Is there a reason > for this? Are there any known "blockers"? Should I be able to make it work, > would patches be accepted? > > 2) CPU-features like POPCNT, AVX are apparently not supported right now (or > at least not with gcc). Also if you build software with the gcc-4.9-port and > specify -march=native gcc wil produce code that actually uses instructions > that are not supported, and then fail with messages like this: > > /tmp//ccF2Aqg7.s: Assembler messages: > /tmp//ccF2Aqg7.s:1668791: Error: no such instruction: `popcntl > -4(%rbp),%eax' > /tmp//ccF2Aqg7.s:1669741: Error: no such instruction: `popcntq > -8(%rbp),%rax' > > -> Are there plans to support more modern CPU-extensions and is there a list > somewhere of which extensions are supported and which ones aren't? I guess > they could be useful for other low-level stuff like encryption, as well.. > --> If not, should the gcc-port be adapted to not offer those extensions > that aren't supported? > > Thanks and best regards, > Hannes >
GCC, OpenMP, -march=
Hi folks, I develop software for work that uses some advanced cpu features and parallelism. While I fully understand that high-performance is not a focus for OpenBSD, I would still like to be able to test basic stuff on my Laptop (which happens to run OpenBSD). So, before I get my hands dirty on this, I'd like to ask if there are structural issues and/or policies preventing those features from working, or whether just no-one was interested up until now (I have done some basic searching but didn't come up with too much). The features in question are: 1) OpenMP with the GCC-port. It is disabled by default. Is there a reason for this? Are there any known "blockers"? Should I be able to make it work, would patches be accepted? 2) CPU-features like POPCNT, AVX are apparently not supported right now (or at least not with gcc). Also if you build software with the gcc-4.9-port and specify -march=native gcc wil produce code that actually uses instructions that are not supported, and then fail with messages like this: /tmp//ccF2Aqg7.s: Assembler messages: /tmp//ccF2Aqg7.s:1668791: Error: no such instruction: `popcntl -4(%rbp),%eax' /tmp//ccF2Aqg7.s:1669741: Error: no such instruction: `popcntq -8(%rbp),%rax' -> Are there plans to support more modern CPU-extensions and is there a list somewhere of which extensions are supported and which ones aren't? I guess they could be useful for other low-level stuff like encryption, as well.. --> If not, should the gcc-port be adapted to not offer those extensions that aren't supported? Thanks and best regards, Hannes