Provide LLVM Compiler Optimization Options for Xojo applications

As has been announced, the next release of Xojo will provide LLVM compilation of 64 bit applications. Eventually, all Xojo apps will be compiled using the LLVM compiler. I have filed a feature request to seek user access to the compiler optimization levels so that we can debug at a low level (which is fast) but create apps with high level optimization if such is desired. I ask all users to consider adding your support to this request if you believe it would be helpful in your work. Here are the details:

<https://xojo.com/issue/39277>

Feature Request: Provide LLVM Compiler Optimization Options for Xojo applications

All Xojo users will benefit from the new LLVM compiler, but in its current implementation, the user has no ability to adjust the optimization levels. We seek the ability to specify the optimization level along the same lines as already provided by the Xojoscript compiler, with some additional options.

This could be a simple PopupMenu or ComboBox providing options such as -00, -01, -02, -Os, -Oz, -03, -04 where
-00 means no optimization (best for debugging, fast compile) and the higher numbers indicate improved optimization but longer compile times. Based on other implementations of the LLVM compiler, I recommend:

-02 (moderate level of optimizations to enable most optimizations. These options are selected by the Xojo team to be the most meaningful for Xojo code, but avoid those that significantly increase compile time.)

-0s (similar to -02 in optimization, but reduces code size)

-0z (similar to 0s but reduces code side further)

-03 (improved optimization over -02 but implements those optimizations that take much longer, or increase code size such as loop unrolling and in-line code)

-04 (highest level of optimization including link-level optimization. This might involve an hour or more of compiler time, and would only be selected for final compiles of working code that need to be fully optimized prior to distribution.)

-01 (somewhere between -00 and -02 but selects those optimizations which are fast. A compromise useful for debugging and testing.)

Why not lets see what LLVM can do for us first, perhaps there is no need (or ability) to have such options

I am sure he his asking this feature based on the alpha testing outcome.

interesting. But I remember that Joe told on XDC that they use a few optimizations which make sense for xojo code like removing extra lock/unlock for xojo objects.

Then this is not right, as Alpha Testers should discuss these things only in the Alpha forum.

The OP does not mention anything indicating that it is based on the knowledge of an Alpha tester – I understand it:

  • as a reasonable request for somebody who knows (at least a little) about LLVM
  • as a reasonable request to gather support for a feature request in Feedback

That was just an assumption based on 64 bit is in alpha testing and he belongs to an alpha group.

[quote=186149:@Eli Ott]The OP does not mention anything indicating that it is based on the knowledge of an Alpha tester – I understand it:

  • as a reasonable request for somebody who knows (at least a little) about LLVM
  • as a reasonable request to gather support for a feature request in Feedback[/quote]
    If so, then it’s jumping the gun a little, as the functionality isn’t solidified yet. And even if the initial release were limited, it is highly unlikely to remain so.

Isn’t that the best time to make requests though, before everything is set?

This really does belong on the alpha channel. This level of detail has not been announced. If it weren’t based on alpha level info, it would be pure speculation.

Although that makes sense at some level; if there is something someone in the alpha group feels is pressing (or even not in the alpha group), shouldn’t that be gaged against a broader audience? We all know that once the core things are defined they are as set in stone as the tablets Moses carried. Then the only recourse left is to fill FRs which are usually too late in the development process because, again, the basic framework is set in stone and to implement the FR will require a redo of the framework.

I get the catch-22 this represents, but I can’t see why to file such request early on is bad. It provides some clear (very clear in this case) direction from a user (or a number of users) of what they deem would be helpful (or necessary). That is the whole idea behind FRs (read “feature” request, not “bug” report).

– When I read the OP I didn’t see the “Alpha Testers” – I never look at that line.
– I spent some free time a bit more than a year ago with LLVM to learn more about compilers and interpreters.
– I know XCode and I know the Apple LLVM Code Generation section in the Build Settings of projects.
– XojoScript has its own optimization with Precompile (optimizationLevel As OptimizationLevels).
– I myself am not an Alpha tester.
And my first reaction to the OP was: that makes sense – not for everybody, but for some of us.

Not from one word in the OP I thought that this was based on “secret” information. I really think this question belongs in this section – not the Alpha section. I second Langue’s comment.

I think Robert Birge is from his point of view, trying to get more support for a feature which in his opinion is very important. When I read his orginal posting, I cannot see anything wrong with it.

He does not share any Alpha channel restricted information with us. And I agree, it is better to make that feature request now then when it is in beta-cycle or the final release.

64 bit was publicly mentioned in the blog comments

http://www.xojo.com/blog/en/2015/05/xdc-2015-recap.php

[quote]Geoff Perlman replied to comment from Adrian E
May 8, 2015 10:35 AM
64 bit for Linux web/console will be available this summer in R3.[/quote]

Isn’t 64bit done with LLVM?

The request is based on information that is only available at this time to alpha testers. But even so, it is asking for the obvious. There is practically zero chance that Xojo will leave the compiler with less optimization than xojoscript. There may or may not be a selection of optimization options available in the initial release, we don’t know yet how that will work out, but it is obvious from what xojo has said, that there will be optimization options in the long run. The request diverts attention from other more important issues. And as I said, it’s premature.

This is not true at all. LLVM is known to come. Optimization levels are a known part of LLVM (or any other important compiler). And there is no other information shared in the OP.

It doesn’t show from the OP that Xojo Inc. plans to introduce optimization levels. Neither does it show that Xojo Inc. does not plan to introduce optimization levels.

It is not true that only alpha testers would know about the implementation of LLVM. There are many blogs and Xojo releases that make it clear that LLVM is coming, and all I am asking is that we have access to a full set of optimization levels. I know it is critical for my applications, and my Xojo apps which are matrix and math heavy are painfully slow compared to the competition.

If we dont ask for it, then we dont deserve to have it. Adding the level of options that I seek would not be a trivial exercise for the Xojo programmers and I do not believe Xojo will do so without our requesting it. I think it is both fair and appropriate that the entire Xojo community discuss the implementation now rather than after the fact.

I am very sorry if anyone is offended by my requesting general support for optimization options at this stage in the process.

THAT appears to be alpha information and not something that should be on the general boards since you agree to keep alpha to alpha and beta to beta while testing is going on as part of being a tester.

This information is on two blogs and is not restricted to the alpha testing folks.

Sorry to disagree. Any information regarding the current alpha build needs to be in the alpha channel.

The difference between what’s been said publicly is that is the official roadmap as given by Xojo. It is purposely vague in details. The current alpha build may have things that won’t be released for R3 or may not be complete yet. So talking about the alpha, “in it’s current implementation”, is verboten.