[cfe-users] Is it possible to translate or forward flags from clang to llc?

[Massimiliano Culpo via cfe-users]

Hi,

I'm looking into what could be the best way to add compiler flags for Clang
to emit optimized code for a specific chip on a given architecture.

Looking at various sources I saw that:

   - llc -march= -mcpu=help

returns the list of the supported cpus which is already helpful. The piece
of information I'm currently missing is how to translate llc's flags like:

   - `-march=x86-64 -mcpu=broadwell`
   - `-march=aarch64 -mattr=+v8.1a,+fp-armv8,+neon,+crc,+crypto`

etc. into something that is understood by clang.

In case the context for doing this is of interest, I'm a core developer of
a package manager focused on HPC (https://github.com/spack/spack) and we'll
use this information to automatically inject optimization flags when
installing application from sources based on the chip selected by the user.

Cheers,
Massimiliano Culpo
___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users

Re: [cfe-users] How to have clang ignore gch directories?

[Paul Smith via cfe-users]

On Thu, 2019-04-25 at 18:53 -0400, Paul Smith via cfe-users wrote:
> On Thu, 2019-04-25 at 14:38 -0700, Richard Smith wrote:
> > > How can I tell clang to just ignore the GCC-specific precompiled
> > > headers, or equivalently ignore precompiled headers altogether?  I
> > > can't delete the gch directories because I need them for my build.
> > > I've read through the clang docs and can't find any likely-looking
> > > options.
> > > 
> > > It's really frustrating when clang tries to appropriate GCC-specific
> > > options and configurations when it's not actually compatible with
> > > them.  It makes modern multi-compiler development so unnecessarily
> > > difficult.
> > 
> > Sorry about that. Clang is trying to be a transparent drop-in
> > replacement for build systems that are designed for GCC, and that
> > means that -include needs to automatically pick up a corresponding
> > .pch / .gch file if a prior build step put one there. Unfortunately
> > we don't do any validation to check whether that's Clang's file or
> > one generated by GCC at that layer :(

Now that CMake 3.16 supports precompiled headers directly, this problem
will only get more and more pronounced as people try to switch to it and
discover it completely breaks their environment.

Of course the built-in CMake support for PCH doesn't try to use the
grotesque hacks that my internal implementation was forced to resort to to
make this work, so I was sad.

So I grabbed a Git clone of the clang source and wrote a patch:
https://bugs.llvm.org/show_bug.cgi?id=41579

I did not try to write a test or anything.  Hopefully someone with some
clang code fu can fix it up to be acceptable and apply it, to stop the
madness.

It may be better to have the code check affirmatively for clang PCH files
instead of ignoring GCC PCH files, but I don't know what the file format
for clang PCH files is and I don't use clang so I didn't try to create one
to find out.

___
cfe-users mailing list
cfe-users@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users