Hello
I’m working on a new back-end for llvm, and we’ve run into a problem. As soon as for example pointers are involved compilation fails, because the front-end is running for x86_64, so the pointers are i64. Looking at compiling llvm-gcc by hand I saw no easy way of adding a new back-end (branches/release_28), so I went with clang (same release) and added the appropriate parts to lib/Basic/Target.cpp. It now accepts -arch MYTARGET, but if you use -emit-llvm (which we have to for the time being), it says:
clang: warning: argument unused during compilation: ‘-arch MYTARGET’
…and the output has the x86_64 triple and datalayout anyway. How are you supposed to develop new back-ends if neither compiler can cross-compile? Target is a DSP, so native compile is entirely impossible.
Thank you for your time
Per Fagrell
Hello Per,
...and the output has the x86_64 triple and datalayout anyway. How are you
supposed to develop new back-ends if neither compiler can cross-compile?
Target is a DSP, so native compile is entirely impossible.
clang support for cross-compilation definitely requires alot of care.
It the meantime you can forward a target triplet to clang via
-ccc-host-triple hidden command line option.
This worked quite well! Seems to me it definitely shouldn’t be a hidden option.
Compiling with the new (correct) triple, llvm has started taking the register arguments and putting them on the stack. Is there an easy way to stop this, or do I have to match/rebuild the dag somehow?
//Per
Per,
Compiling with the new (correct) triple, llvm has started taking the
register arguments and putting them on the stack. Is there an easy way to
stop this, or do I have to match/rebuild the dag somehow?
Ok.
1. Are you running with optimizations enabled?
2. Have you implemented the necessary hooks inside your
TargetRegisterInfo class? Which will recognize reg-reg copies, loads /
stores to stack slots, etc.