Re: GCC, OpenMP, -march=

2016-03-27 Thread Hannes Hauswedell

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=

2016-03-27 Thread Hannes Hauswedell

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=

2016-03-27 Thread Hannes Hauswedell

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=

2016-03-26 Thread Pascal Stumpf
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=

2016-03-26 Thread Stuart Henderson
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=

2016-03-26 Thread Karel Gardas
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 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?
>
> 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=

2016-03-26 Thread Hannes Hauswedell

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