How to force clang use llvm assembler instead of system? - c++

I'm working on LLVM/Clang fork (for AVR). How can i force Clang Driver to use LLVM assembler instead of system one?
MBA-Anton:bin asmirnov$ ./clang++
-I/Applications/avr.app/Contents/Resources/Java/hardware/avr/cores/avr -I/Applications/avr.app/Contents/Resources/Java/hardware/avr/variants/standard
/var/folders/64/fwfkm1k51zbd4_c5lwpsbljh0000gn/T/build5450310618632673119.tmp/Blink.cpp
-o /tmp/Blink.avr.hex -I /Applications/avr.app//Contents/Resources/Java/hardware/tools/avr/avr/include/
--target=avr -O1 -v
And it uses LLVM clang compiler (not system, correct):
clang version 3.6.0 (https://github.com/4ntoine/clang.git 0d08deedd548d964f63cf896ae9acb8d878a5fd8) (https://github.com/dylanmckay/avr-llvm.git 447b58bced825fa7bea31f3882f277535cc9fca6)
Target: avr
Thread model: posix
"/Users/asmirnov/Documents/dev/src/llvm_dylan/installed/bin/clang" -cc1 ...
But system assembler (incorrect):
"/usr/bin/as" -o ...
It should use LLVM's llvm-as as it "knows" AVR target (opcodes, etc). How can i force it use LLVM's assembler?

You can use clang to emit LLVM IR code by using the option -emit-llvm.
Let's say you want to compile a C file into LLVM IR:
clang -emit-llvm -c file.c
It will create a LLVM bytecode file file.bc. You will be able to compile the file with llc.

Related

How to emit optimisation reports using Apple clang 3.5?

According to the documentation, clang supports options to emit optimisation reports:
When the pass makes a transformation (-Rpass).
When the pass fails to make a transformation (-Rpass-missed).
When the pass determines whether or not to make a transformation (-Rpass-analysis).
They provide the following example command line:
$ clang -O2 -Rpass=inline code.cc -o code
When I try this, I get an error:
$ clang src/test/tests.cpp -Rpass=inline
clang: error: unknown argument: '-Rpass=inline'
scons: *** [build/test/tests.o] Error 1
scons: building terminated because of errors.
My clang version is:
$ clang --version
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix
Is this option not available on Mac OS? Is the documentation erroneous? Or am I doing it wrong? If so, how to do it right?
Works for Debian clang-3.5.0-6, so this is probably Apple clang restriction.
% clang++ -O2 -Rpass=inline foo.cpp
foo.cpp:11:2: remark: _ZN1CC2Ev inlined into main [-Rpass=inline]
P* p = new C();
^
% clang --version
Debian clang version 3.5.0-6 (tags/RELEASE_350/final) (based on LLVM 3.5.0)
Target: i386-pc-linux-gnu
Thread model: posix

clang -cc1 and system includes

I have the following file foo.cpp:
#include <vector>
struct MyClass
{
std::vector<int> v;
};
It can be successfully compiled with clang (I'm using clang 3.3 on Ubuntu 13.04 32bit):
clang++ -c foo.cpp
Now I want to print AST:
clang++ -cc1 -ast-print foo.cpp
and I've got the following error
foo.cpp:1:10: fatal error: 'vector' file not found
#include <vector>
^
struct MyClass {
};
1 error generated.
It looks like clang++ -cc1 doesn't know about system include files etc.
I'm wondering how to set up includes for clang++ -cc1?
You need to set up the right include paths.
on my system I added
-I/usr/include/i386-linux-gnu/c++/4.8 -I/usr/include/c++/4.8
to the compiler flags. The first one was so that it could find
bits/c++config.h
Of course the 4.8 is due to the fact I am using a compiler compatible with g++-4.8
I also added
-std=c++11 -stdlib=libstdc++
as compiler options.
Hope this helps
It's a Frequently Asked Question
#john is correct. For posterity, the relevant portions of the FAQ are (with names tweaked to match the question) :
clang -cc1 is the frontend, clang is the driver. The driver invokes the frontend with options appropriate for your system. To see these options, run:
$ clang++ -### -c foo.cpp
Some clang command line options are driver-only options, some are frontend-only options. Frontend-only options are intended to be used only by clang developers. Users should not run clang -cc1 directly, because -cc1 options are not guaranteed to be stable.
If you want to use a frontend-only option (“a -cc1 option”), for example -ast-dump, then you need to take the clang -cc1 line generated by the driver and add the option you need. Alternatively, you can run clang -Xclang <option> ... to force the driver [to] pass <option> to clang -cc1.
I did the latter (-Xclang) for emitting precompiled headers:
/usr/bin/clang++ -x c++-header foo.hpp -Xclang -emit-pch -o foo.hpp.pch <other options>
^^^^^^^
Without the -Xclang, clang++ ignored the -emit-pch. When I tried -cc1, I had the same problem as the OP — clang++ accepted -emit-pch but didn't have the other options the driver normally provides.

cc1.exe fail to initialize modified dragonegg.dll

I want to generate LLVM bitcode rather than LLVM IR, from C and C++ source.
Original version of dragonegg works correctly.
Since it doesn't have a function to emit LLVM bitcode, I tried to add that, but it doesn't work.
What's wrong with my modification?
gcc -fplugin=dragonegg.dll -fplugin-arg-dragonegg-emit-llvm -I ..\include -c test.c
cc1.exe: error: fail to initialize plugin dragonegg.dll
I posted my patch to gist.
https://gist.github.com/vroad/1f2dcd2c37e03005a349
I compiled latest LLVM and dragonegg with plugin-enabled gcc for Windows.
SourceForge.net: MinGW - Minimalist GNU for Windows: http://sourceforge.net/mailarchive/message.php?msg_id=28248366

LLVM & Clang can't compile for a supported arch

Under Ubuntu 64 bit I got
llc --version
LLVM (http://llvm.org/):
LLVM version 3.1
Optimized build with assertions.
Built Oct 15 2012 (18:15:59).
Default target: x86_64-pc-linux-gnu
Host CPU: btver1
Registered Targets:
arm - ARM
mips - Mips
mips64 - Mips64 [experimental]
mips64el - Mips64el [experimental]
mipsel - Mipsel
thumb - Thumb
x86 - 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64
I can't do this
clang -march=arm -x c++ /tmp/cpp.cpp
error: unknown target CPU 'arm'
I'm missing something here ? Why I can't compile for ARM ?
-march is LLVM's internal tools command line option and is not connected with clang at all. If you need to compile for other target you need to specify the target triplet. This can be done in several ways (I do not remember offhand, whether they work with 3.1, but they definitely work with 3.2):
Make a link from clang to your-target-triple-clang, e.g. to
arm-none-linux-gnueabi-clang and compile everything via it
Provide -target option, e.g. clang -target arm-none-linux-gnueabi
To get a list of options of the clang compiler, use:
clang -cc1 -help
To specify the target, use -triple:
clang -cc1 -triple "arm-vendor-os" filename
where "vendor" and "os" should be replaced with the actual vendor and OS name. It can also be replaced with unknown.
-triple is a string of the form ARCHITECTURE-VENDOR-OS or ARCHITECTURE-VENDOR-OS-ENVIRONMENT. For example: x86_64-apple-darwin10
the llvm linker links for the host, which is only one of the targets, it wont link to every target in the list. it will definitely compile for any target. Basically clang goes from C/C++ to bytecode, then llc takes bytecode and makes assembly for the specific target (new experrimental option to take the bytecode straight to object file) then you need to get a cross assembler and a cross linker to take it the final mile (I use gnu binutils). Unfortunately I found that clang to bytecode is not completely generic (I had hoped and expected that it would be), it does in fact change the target independent output based on the target. The example below using the host triple instead of using -march allowed for my examples to build properly on more hosts.
ARMGNU?=arm-none-eabi
LOPS = -Wall -m32 -emit-llvm -ccc-host-triple $(ARMGNU)
OOPS = -std-compile-opts
LLCOPS = -march=thumb -mtriple=$(ARMGNU)
clang $(LOPS) -c blinker03.c -o blinker03.clang.bc
opt $(OOPS) blinker03.clang.bc -o blinker03.clang.thumb.opt.bc
llc $(LLCOPS) blinker03.clang.thumb.opt.bc -o blinker03.clang.thumb.opt.s
$(ARMGNU)-as blinker03.clang.thumb.opt.s -o blinker03.clang.thumb.opt.o
$(ARMGNU)-ld -o blinker03.clang.thumb.opt.elf -T memmap vectors.o blinker03.clang.thumb.opt.o
I have not, but before long will experiment with using the llc straight to object (actually I tried it on a simple test but have not used it on anything larger or posted it anywhere).
You're confusing your flags. clang's -march= wants a processor family. You probably meant to use clang -arch arm instead.
As this comment says this option it's not supported yet under linux, for now.
"-arch arm" is equivalent to "-arch armv4t" in clang. I suppose that a generic "arm" target is not allowed with "-march=", which should require something more precise, such as "armv6", "thumbv7", "armv4t", ...
Try selecting a specific subarch.
Starting Clang 11 (trunk), the list of supported target architectures could be handily printed using the newly added -print-targets flag.

How to generate assembly code with clang in Intel syntax?

As this question shows, with g++, I can do g++ -S -masm=intel test.cpp.
Also, with clang, I can do clang++ -S test.cpp, but -masm=intel is not supported by clang (warning argument unused during compilation: -masm=intel). How do I get intel syntax with clang?
As noted below by #thakis, newer versions of Clang (3.5+) accept the -masm=intel argument.
For older versions, this should get clang to emit assembly code with Intel syntax:
clang++ -S -mllvm --x86-asm-syntax=intel test.cpp
You can use -mllvm <arg> to pass in llvm options from the clang command line. Sadly this option doesn't appear to be well documented, and thus I only found it by browsing through the llvm mailing lists.
As of clang r208683 (clang 3.5+), it understands -masm=intel. So if your clang is new enough, you can just use that.
Presuming you can have Clang emit normal LLVM byte codes, you can then use llc to compile to assembly language, and use its --x86-asm-syntax=intel option to get the result in Intel syntax.