[cfe-dev] Behavior of -mcpu

Craig Topper via cfe-dev cfe-dev at lists.llvm.org
Fri Mar 1 11:49:05 PST 2019


According to gcc's documentation, -march implies -mtune for x86. Which
matches what clang does without having -mtune. Their documentation also
says -mcpu is a depcrated synonym for -mtune. So I'm not sure that -mcpu
ever did -march and -mtune together on gcc at least for x86

~Craig


On Fri, Mar 1, 2019 at 8:27 AM David Greene via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Kristof Beyls <Kristof.Beyls at arm.com> writes:
>
> > Hi David,
> >
> > I thought that mtune just wasn’t supported for any target in clang,
> > but I may be wrong.
> > FWIW, the following thread discusses what would be needed to implement
> > support for mtune:
> > http://lists.llvm.org/pipermail/llvm-dev/2017-October/118344.html
> > AFAIK, so far nobody has worked on implementing that proposal.
>
> Now I'm (more) confused.  If -mtune doesn't work and -mcpu isn't
> supported for x86-64 (I get a warning about an unused option) how do
> users compile for a target like skylake-avx512 and have the optimizer
> tune for it?
>
>                             -David
>
> >     On 28 Feb 2019, at 21:42, David Greene via cfe-dev
> >     <cfe-dev at lists.llvm.org> wrote:
> >
> >
> >
> >     Stefan Teleman <stefan.teleman at gmail.com> writes:
> >
> >         On Thu, Feb 28, 2019 at 2:09 PM David Greene via cfe-dev
> >         <cfe-dev at lists.llvm.org> wrote:
> >
> >
> >             Interesting. I am observing different behavior between -
> >             mcpu= and
> >             -march= -mtune= with aarch64-unknown-linux-gnu:
> >
> >         We never supported -mtune=thunderx2t99.
> >
> >         -mcpu=thunderx2t99
> >         -march=armv8.1-a+lse
> >
> >     This is problematic for users. If clang interprets command-line
> >     flags
> >     differently based on subtarget, how are users to know what to pass
> >     to
> >     clang to get, say, the best performance, or best code size, or
> >     whatever?
> >
> >     Users don't expect to have to set up their build systems to pass
> >     different -mcpu/-march/-mtune flags based on what they are
> >     targeting.
> >     They want to do something like this and be done with it:
> >
> >     TARGET=$(call get_triple)
> >     ARCH=$(call get_arch)
> >     TUNE=$(call get_tune)
> >
> >     CFLAGS += --target ${TARGET} -march=${ARCH) -mtune=${TUNE}
> >
> >     They could, but probably won't be happy to, do:
> >
> >     ifeq (TARGET,aarch64-unknown-linux-gnu)
> >     ifeq (TUNE,thunderx2t99)
> >     # -mtune unsupported
> >     CFLAGS += -mcpu=${TUNE}
> >     else ifeq (TUNE,anothertarget)
> >     # -mcpu unsupported
> >     CFLAGS += -march=${ARCH} -mtune=${TUNE}
> >     else ifeq (TUNE,thirdtarget)
> >     CFLAGS += -mtune=${TUNE}
> >     endif
> >     else ifeq(TARGET,x86_64-unknown-linux-gnu)
> >     ifeq (TUNE,skylake-avx512)
> >     # -mtune unsupported
> >     CFLAGS += -mcpu=${TUNE}
> >     else ifeq (TUNE,broadwell)
> >     # -mcpu unsupported
> >     CFLAGS += -march=${ARCH} -mtune=${TUNE}
> >     endif
> >     else ifeq(TARGET,third-target-triple)
> >     # -mcpu and -mtune unsupported
> >     CFLAGS += -march=${ARCH}
> >     endif
> >
> >     It's hard enough for users to support building for multiple
> >     subtargets
> >     without having to deal with basic compiler behavior differences
> >     per
> >     subtarget.
> >
> >     Perhaps there is some capability of clang I'm not understanding.
> >     What's
> >     the expected/canonical way to tune compilation for a subtarget?
> >
> >     -David
> >     _______________________________________________
> >     cfe-dev mailing list
> >     cfe-dev at lists.llvm.org
> >     https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190301/2587252c/attachment.html>


More information about the cfe-dev mailing list