Hello,
I was trying to compile a simple program with the CppBackend like so:
$ clang str_arg.c -emit-llvm -S
$ llc -march=cpp str_arg.ll
It produces a file str_arg.cpp as expected, however it doesn’t seem that the resulting file is correct. For once, it includes <llvm/Analysis/Verifier.h> which seems to have been moved to llvm/IR/Verifier.h as far back as 2013.
My question is this: is the CppBackend supposed to work? If so, what am I missing?
Listing of str_arg.c:
#include <stdio.h>
void i(unsigned index, char *string) {
printf(“%d %s\n”, index, string);
}
int main() {
i(10, “foo”);
return 0;
}
clang version:
clang version 3.7.1 (http://llvm.org/git/clang.git 0dbefa1b83eb90f7a06b5df5df254ce32be3db4b) (http://llvm.org/git/llvm.git 33c352b3eda89abc24e7511d9045fa2e499a42e3)
Target: x86_64-unknown-linux-gnu
Thread model: posix
llc version:
LLVM (http://llvm.org/):
LLVM version 3.7.1
Optimized build.
Built Apr 4 2016 (15:04:44).
Default target: x86_64-unknown-linux-gnu
Host CPU: ivybridge
Registered Targets:
aarch64 - AArch64 (little endian)
aarch64_be - AArch64 (big endian)
amdgcn - AMD GCN GPUs
arm - ARM
arm64 - ARM64 (little endian)
armeb - ARM (big endian)
bpf - BPF (host endian)
bpfeb - BPF (big endian)
bpfel - BPF (little endian)
cpp - C++ backend
hexagon - Hexagon
mips - Mips
mips64 - Mips64 [experimental]
mips64el - Mips64el [experimental]
mipsel - Mipsel
msp430 - MSP430 [experimental]
nvptx - NVIDIA PTX 32-bit
nvptx64 - NVIDIA PTX 64-bit
ppc32 - PowerPC 32
ppc64 - PowerPC 64
ppc64le - PowerPC 64 LE
r600 - AMD GPUs HD2XXX-HD6XXX
sparc - Sparc
sparcel - Sparc LE
sparcv9 - Sparc V9
systemz - SystemZ
thumb - Thumb
thumbeb - Thumb (big endian)
x86 - 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64
xcore - XCore
Kind regards,
1 Like
Stanislav Manilov via llvm-dev <llvm-dev@lists.llvm.org> writes:
Hello,
I was trying to compile a simple program with the CppBackend like so:
$ clang str_arg.c -emit-llvm -S
$ llc -march=cpp str_arg.ll
It produces a file `str_arg.cpp` as expected, however it doesn't seem that
the resulting file is correct. For once, it includes
`<llvm/Analysis/Verifier.h>` which seems to have been moved to
`llvm/IR/Verifier.h` as far back as 2013.
My question is this: is the CppBackend supposed to work? If so, what am I
missing?
It is supposed to work, but it's definitely broken. I suppose nobody
motivated to fix it has noticed 
Feel free to file a bug on llvm.org/bugs or to try to fix these issues
and send patches. Sorry I don't have a better answer for you.
Stanislav Manilov via llvm-dev <llvm-dev@lists.llvm.org> writes:
Hello,
I was trying to compile a simple program with the CppBackend like so:
$ clang str_arg.c -emit-llvm -S
$ llc -march=cpp str_arg.ll
It produces a file `str_arg.cpp` as expected, however it doesn't seem that
the resulting file is correct. For once, it includes
`<llvm/Analysis/Verifier.h>` which seems to have been moved to
`llvm/IR/Verifier.h` as far back as 2013.
My question is this: is the CppBackend supposed to work? If so, what am I
missing?
It is supposed to work, but it's definitely broken. I suppose nobody
motivated to fix it has noticed
Feel free to file a bug on llvm.org/bugs or to try to fix these issues
and send patches. Sorry I don't have a better answer for you.
I'm not motivated enough to fix it either, but maybe it would be a good idea to have a unit test for it that takes in the bitcode we use to check all of the backward compatibility guarantees, and makes sure that it is capable of round-tripping them.
Jon
Yes, it’s quite obviously dead and should be deleted.
When I brought this up last time – after realizing that it wasn’t actually a backend that targetted c++ (which might be useful), but rather just something that emitted IR by calling llvm C++ functions (which really isn’t IMO) – someone also pointed out that it also really ought to be using IRBuilder…if anyone cared about it.
Care to send a patch deleting it? 
Cheers,
Rafael
On the other hand these requests come back from time to time on the
mailing list and it is still used in many attics of various projects as
a de-facto internal representation to interface with other tools for
technical/marketing/political/... reasons.
So sending a patch to resurrect it in a more modern new life might be
also considered instead of many people crafting some half-working
ashamed kludges far from the sight...
Hi,
> Care to send a patch deleting it?
On the other hand these requests come back from time to time on the
mailing list and it is still used in many attics of various projects as
a de-facto internal representation to interface with other tools for
technical/marketing/political/... reasons.
Doesn't seem like it is, if it seems to be broken since some 2013 changes.
It might be in use for projects using older llvm releases, of course.
But those haven't updated their llvm library for a long time, so this
wouldn't be their major problem.
So sending a patch to resurrect it in a more modern new life might be
also considered instead of many people crafting some half-working
ashamed kludges far from the sight...
Not really. There's no reason to spend the effort just because "in the
future someone might use it".
If you're saying "I have some half-working things and CppBackend would
be awesome for me", then I guess no one would object to you working on
it, and people would actually help if you needed advice/patch review,
etc.
But if we have no one actively interested, and there has been no
active development to the point where it's plain broken since a long
time ago, then we probably want to start proposing its deletion.
There's no point in having people who aren't interested in maintaining
it do all this work if the backend can be so out of date and no one
notices.
If it's not usable now and almost no one complains about it being
broken (outside the occasional "Is this working? No.", will those
people notice if it's gone?
Thank you,
Filipe
Hi,
There is another benefit to keeping the CppBackend: it’s great for learning how to use the IR and the C++ API in particular, as can be seen from this SO Q&A: http://stackoverflow.com/questions/16656855/llvm-ir-string-initialization
But I’ll understand if it’s considered too much of a burden to keep. I can send a patch for the part that I was trying to use, but there’s probably a lot to fix for it to fully work.
Cheers,
Except that it shows you a bad way to use the APIs, since it doesn’t use IRBuilder which is by far the better way to build IR in the C++ API.
[-- I was, in fact, looking for a way to generate a global constant representing a string literal, and that’s when (even the broken) CppBackend came in handy. I don’t think the IRBuilder can be used, but perhaps I’m wrong. --] While writing this, I checked, and there are CreateGlobalString and CreateGlobalStringPtr in IRBuilder, which seems to be what I needed.
Case in point. CppBackend taught me the wrong way to use the API.
The usual advice I provide people is “see what Clang does with an equivalent C construct”
As in “look at the source of clang” or as in “look at the -S -emit-llvm” output? If you mean the former, then would that be easy for someone who hasn’t seen the clang source before?
As in "look at the source of clang" or as in "look at the -S -emit-llvm"
output? If you mean the former, then would that be easy for someone who
hasn't seen the clang source before?
Generally the latter - then potentially set some breakpoints & look at the
clang source if you're looking for the right APIs.
It's not as easy as the CppBackend (if the CppBackend were up to date) but
not too bad, I don't think.
I’ve been looking at the generated IR (together with the IR language reference and the docs for the API), but I could figure out how to generate it myself.
But your suggestion to look at the clang source is a good idea. Thanks!
I've been looking at the generated IR (together with the IR language
reference and the docs for the API), but I could figure out how to generate
it myself.
But your suggestion to look at the clang source is a good idea. Thanks!
Bonus tip: Once you know the IR you want, you can probably find/guess the
instruction or other llvm value you're interested in. Set a breakpoint in
the ctor of that type (eg: break llvm::StoreInst::StoreInst) & then look at
the backtrace to see how/where it's built inside clang.
after realizing that it wasn’t actually a backend that targetted c++ (which might be useful)
Exact same thing just happened to me… it’s not obvious, especially when reading the llc info:
$ llc -version
Registered Targets:
arm - ARM
arm64 - ARM64 (little endian)
cpp - C++ backend
x86 - 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64
...
- If not delete it, then at least adjust the description? E.g. “LLVM C++ API code” following ? Could also the name change to “cppapi”? * Has there ever been an attempt to implement a real C++ Backend? Without having done research in that direction - shouldn’t that be quite straightforward? Anyone aware of technical difficulties? Cheers, Stefan
* Has there ever been an attempt to implement a real C++ Backend? Without
having done research in that direction - shouldn't that be quite
straightforward? Anyone aware of technical difficulties?
The first question probably is what it would be useful for?
This was more about technical feasibility. IMHO usefulness is implicitly
given. Anyway, don't know if I get your point right..?