[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