clang++: error: the clang compiler does not support '-march=native'

[Warner Losh]

On Sat, Feb 6, 2016 at 6:57 PM, Erich Dollansky <erichsfreebsdlist at alogt.com
> wrote:

> Hi,
>
> On Sat, 6 Feb 2016 15:49:14 -0700
> Warner Losh <imp at bsdimp.com> wrote:
>
> > On Sat, Feb 6, 2016 at 2:01 PM, Erich Dollansky
> > <erichsfreebsdlist at alogt.com
> > > wrote:
> >
> > > Hi,
> > >
> > > compiling on a Raspberry Pi B 2 on FreeBSD 11 gives me above's error
> > > message.
> > >
> > > A Internet search shows that this message does not exist.
> > >
> > > The program compiles using the same make file on FreeBSD 10 both on
> > > x86 and an Raspberry Pi B using the default compilers.
> > >
> > > Did support for 'march' get removed?
> > >
> >
> > As far as I can tell, it has never worked for either gcc or clang.
> >
> this is what I would have liked to find out. Intel claims speed gains
> of some 40% on their CPUs depending on the work load using gcc.
>
> Getting a few per cent on a Raspberry for free would make a real
> difference.
>

Well, the -march=<actual-cpu-here> args work, just not -march=native.
The exact details of the core aren't exported from the kernel, so the
compiler can't easily query them to guess at the best code generation
to use. I think it would be a useful feature, but it just isn't one we have
yet.

There are some -march values that get so aggressive about optimization
that they reveal some alignment issues. However, I think we've kill them
all. If not, we'd love to hear about it.

I know that the -march=arm1176 works well for the RPi B. Last time I
tried it, the -march=cortex-a7 had some alignment issues. Since then
I've seen fixes go into the tree and I haven't tried again. Reports from
elsewhere indicate that this will give tens of percent in improvement
depending on the workload.

Warner