[llvm-dev] Do LLVM passes have different behavior depending on the target triple and/or the optimization level selected?

[Michael Kuperstein via llvm-dev]

Hi Ricardo,

Yes, the optimizer's behavior can, and does, change depending on the target
triple, so you definitely need to pass the target triple to the optimizer
when cross-compiling.
Furthermore, even your frontend will often care about the triple (for a
simple example, consider sizeof in C). So you really ought to use the same
triple through the entire compilation process.

Michael

On Tue, May 10, 2016 at 10:21 AM, Ricardo Nobre via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi again,
>
>
> Thanks for answering my previous question :)
>
> There is something else I do not understand about the passes in LLVM.
>
> Does the behavior of some LLVM passes change depending on the 'target
> triple' passed (either inside the LLVM IR or passed as command line
> parameter) to the LLVM Optimizer (LLVM 'opt' tool)?
> Is the behavior of the passes when called by LLVM 'opt' target specific
> (architecture/subarchitecture, vendor, operating system, etc...)?
>
>
> If that is the case, then when I'm cross-compiling for a given target
> (e.g., target SPARC-ELF on a X86-LINUX machine) I must always pass the
> target triple.
> If that is not the case, they I only need to pass the target triple to the
> 'llc' static compiler when gerating the assembly code for the target
> platform.
>
>
> Additionally, someone pointed me to this commit, suggesting that the
> behavior of some passes depends on the selected optimization level.
> Is this correct?
>
> If so, is it possible to execute only some of the passes in -O2 (or in a
> different order), but have them individually behaving as if -O2 was being
> used?
>
> Is there any direct mechanism to control compiler passes individually?
>
>
> Regards,
> Ricardo
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160510/32f314f1/attachment.html>