Harel Cain
2011-Oct-27 14:31 UTC
[LLVMdev] Resolving sizeof's; target triples; type optimizations
Hi all, A few different though somewhat related questions here. I'm really grateful for your answers! 1. From a previous question I know that sizeof's are resolved into literals 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 it? 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 char 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 file affect this in any way? 2. What is that "target triple" as appears in the IR code? Who inserts it? Who takes note of it, if at all? Can the front-end be made to use some other triple than the native one? Does it affect the backends at all? 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 all other optmizations, i. e. not using -O0 or something similar). Many thanks!! Harel Cain -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111027/41ab821a/attachment.html>
Eli Friedman
2011-Oct-27 15:53 UTC
[LLVMdev] Resolving sizeof's; target triples; type optimizations
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 grateful > for your answers! > > 1. From a previous question I know that sizeof's are resolved into literals > 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 it? > 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 char > 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 file > affect this in any way?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.> 2. What is that "target triple" as appears in the IR code? Who inserts it? > Who takes note of it, if at all? Can the front-end be made to use some other > 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 all > 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. -Eli
Harel Cain
2011-Oct-27 17:55 UTC
[LLVMdev] Resolving sizeof's; target triples; type optimizations
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 backends. 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 platforms. Thanks again, Harel Cain 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 > grateful > > for your answers! > > > > 1. From a previous question I know that sizeof's are resolved into > literals > > 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 > it? > > 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 > char > > 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 > file > > affect this in any way? > > > > > 2. What is that "target triple" as appears in the IR code? Who inserts > it? > > Who takes note of it, if at all? Can the front-end be made to use some > other > > 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 > all > > 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. > > -Eli >-- Quidquid latine dictum sit, altum videtur. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111027/b8eb9864/attachment.html>
Possibly Parallel Threads
- [LLVMdev] Resolving sizeof's; target triples; type optimizations
- [LLVMdev] Resolving sizeof's; target triples; type optimizations
- [LLVMdev] Resolving sizeof's; target triples; type optimizations
- [LLVMdev] Passing arguments to opt via clang
- [LLVMdev] Weak private linkage for Objective C