[LLVMdev] Resolving sizeof's; target triples; type optimizations
harel.cain at gmail.com
Thu Oct 27 10:55:15 PDT 2011
Thanks for the answers.
> See http://llvm.org/docs/FAQ.html#platformindependent . If you're
> dealing with C code, it isn't too hard to add a new target to clang;
> send an email to cfe-dev if you need help with that. The "target
> datalayout" information is purely a hint to the optimizers.
My experience this far has been mainly with using llvm-gcc and llvmc,
especially using llvmc as a cross-compiler, with passing the correct flags
(mainly -march) to llc via llvmc so as to pick for example ARM, MIPS and C
In doing this, I'm essentially overriding any "target triple" existing in
the IR, breaking up the process into a multi-stage operation (llvm-gcc, opt
and llc running independently) and picking whatever target I want, right?
What's the proper way to use clang as a cross-compiler (for example with the
ARM or C backends) then?
The reason I want to avoid optimizing 8 x i8 into i64 is that I use the C
backend (with the resultant C files as input to legacy compilers on esoteric
platforms), and i64s turn into long longs that don't exist on those
On Thu, Oct 27, 2011 at 17:53, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Thu, Oct 27, 2011 at 7:31 AM, Harel Cain <harel.cain at gmail.com> wrote:
> > Hi all,
> > A few different though somewhat related questions here. I'm really
> > for your answers!
> > 1. From a previous question I know that sizeof's are resolved into
> > early in the front-end before IR is even emitted. It seems that they are
> > resolved into whatever value is correct for the host machine. But if one
> > wishes to then take the IR and emit assembly code for some other platform
> > (in other words, to cross-compile), what's the correct way to go about
> > How to make the front-end resolve the sizeof's according to some other
> > target triple? For example, the sizeof of a C struct of one int and one
> > is resolved into 8 and not 5, but for some platforms out there 5 might be
> > the correct answer. Will the "target datalayout" information in the IR
> > affect this in any way?
> > 2. What is that "target triple" as appears in the IR code? Who inserts
> > Who takes note of it, if at all? Can the front-end be made to use some
> > triple than the native one? Does it affect the backends at all?
> In the workflow for compiling C, the clang frontend sets it, and the
> backend uses it to pick the correct target the generate assembly for.
> > 3. In my code, I see an array of 8 x i8 being optimized into i64 (so that
> > memcpy is then optimized into mov) by some optimization
> transformation(s). I
> > want to prevent this from happening. What optimization does this kind of
> > type replacement? How can one prevent it alone from running (but keeping
> > other optmizations, i. e. not using -O0 or something similar).
> IIRC, instcombine does this; I'm not sure why you would want to
> disable it, though.
Quidquid latine dictum sit, altum videtur.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev