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