[LLVMdev] Target-specific defaults for LLVM tools?

[David Jones]

What is the preferred method for compiler (frontend) developers to optimize
and generate target machine code from IR?

At one point I found a tutorial that recommended simply dumping the IR to a
file and spawning llc to do the job.

Up until now I have "manually" created a TargetMachine, PassManager, etc.
to generate my object code. The initial version of my code was cribbed from
llc for LLVM 3.2, and has since been updated for 3.5.1.

However, with every new release of LLVM, the API to the backend
optimization and code generation passes changes.  The changes from 3.5.1 to
3.6 are quite significant. If I'm lucky, the impact of a change is that my
C++ code refuses to compile, and I have to fix. If I'm unlucky, the impact
may be that my code compiles and runs, but LLVM works suboptimally -
perhaps some optimizations don't happen. (This can happen if a newer API
expects me to do some step which was not required in earlier releases, and
there is no assert to catch it.)

As an alternative, I am seriously considering "simply dumping the IR to a
file and spawning llc" to perform my backend work. The API to create IR is
much more stable than the API to do useful things with it. Furthermore,
it's a lot easier to manually debug IR that has been dumped to a file.
Finally, I can spawn multiple, independent, concurrent invocations of llc
on a multi-core machine. I needn't worry about concurrency, as the standard
Linux fork/waitpid type calls will suffice. Given that 90% of my runtime is
spent inside LLVM, I get 90% of the benefit of a fully concurrent design
with almost zero work.

But now it seems that this usage model is frowned upon.

What is the recommended usage model?


On Tue, Mar 17, 2015 at 2:32 PM, Owen Anderson <resistor at mac.com> wrote:

>
> On Mar 17, 2015, at 11:13 AM, Dario Domizioli <dario.domizioli at gmail.com>
> wrote:
>
> What does the community think?
> Discuss. :-)
>
>
> Devil’s advocate: opt, llc, lli, etc. are development/debugging tools for
> LLVM developers, not for end users, and the project optimizes their
> functionality for that use case.
>
> —Owen
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150317/f69caa0b/attachment.html>