<div dir="ltr">Thanks for the answers. <br><br>> See <a href="http://llvm.org/docs/FAQ.html#platformindependent" target="_blank">http://llvm.org/docs/FAQ.html#platformindependent</a> .  If you're<br>> dealing with C code, it isn't too hard to add a new target to clang;<br>
> send an email to cfe-dev if you need help with that.  The "target<br>> datalayout" information is purely a hint to the optimizers.<br><br>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 backends. <br>
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?<br>
<br>What's the proper way to use clang as a cross-compiler (for example with the ARM or C backends) then?<br><br>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 platforms. <br>
<br>Thanks again,<br>Harel Cain<br><br><div class="gmail_quote">On Thu, Oct 27, 2011 at 17:53, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, Oct 27, 2011 at 7:31 AM, Harel Cain <<a href="mailto:harel.cain@gmail.com">harel.cain@gmail.com</a>> wrote:<br>
> Hi all,<br>
><br>
> A few different though somewhat related questions here. I'm really grateful<br>
> for your answers!<br>
><br>
> 1. From a previous question I know that sizeof's are resolved into literals<br>
> early in the front-end before IR is even emitted. It seems that they are<br>
> resolved into whatever value is correct for the host machine. But if one<br>
> wishes to then take the IR and emit assembly code for some other platform<br>
> (in other words, to cross-compile), what's the correct way to go about it?<br>
> How to make the front-end resolve the sizeof's according to some other<br>
> target triple? For example, the sizeof of a C struct of one int and one char<br>
> is resolved into 8 and not 5, but for some platforms out there 5 might be<br>
> the correct answer. Will the "target datalayout" information in the IR file<br>
> affect this in any way?<br>
<br>
</div><br>
<div class="im"><br>
> 2. What is that "target triple" as appears in the IR code? Who inserts it?<br>
> Who takes note of it, if at all? Can the front-end be made to use some other<br>
> triple than the native one? Does it affect the backends at all?<br>
<br>
</div>In the workflow for compiling C, the clang frontend sets it, and the<br>
backend uses it to pick the correct target the generate assembly for.<br>
<div class="im"><br>
> 3. In my code, I see an array of 8 x i8 being optimized into i64 (so that<br>
> memcpy is then optimized into mov) by some optimization transformation(s). I<br>
> want to prevent this from happening. What optimization does this kind of<br>
> type replacement? How can one prevent it alone from running (but keeping all<br>
> other optmizations, i. e. not using -O0 or something similar).<br>
<br>
</div>IIRC, instcombine does this; I'm not sure why you would want to<br>
disable it, though.<br>
<font color="#888888"><br>
-Eli<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Quidquid latine dictum sit, altum videtur.<br>
</div>