Opened 10 years ago

Last modified 3 years ago

#1371 new task

Add -O3

Reported by: simonmar Owned by:
Priority: normal Milestone:
Component: Compiler Version: 6.6.1
Keywords: Cc: dterei,…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


It has been suggested that we should have an -O3 that trades off code size for speed. Things that we could do include bumping the threshold for some optimisations (inlining, SpecConstr, LiberateCase), and perhaps inlining some operations in the back-end.

Of course we should measure the effect of various settings on nofib/nobench and pick a good combination.

Change History (10)

comment:1 Changed 8 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:2 Changed 8 years ago by simonmar

Operating System: UnknownUnknown/Multiple

comment:3 Changed 8 years ago by igloo

Milestone: 6.10 branch_|_

comment:4 Changed 7 years ago by simonmar

difficulty: Moderate (1 day)Moderate (less than a day)

comment:5 Changed 5 years ago by dterei

Type of failure: None/Unknown

This would also be relevant for the LLVM backend. I haven't enabled every bell and whistle at -O2 so as to keep compile speeds down. -O3 would be nice to be a little more 'experimental' in its aggressiveness.

comment:6 Changed 5 years ago by dterei

Cc: dterei added

comment:7 Changed 4 years ago by morabbin

We could certainly repeat Don's process for finding the optimal flags to GHC/LLVM on nofib/nobench. Or is that what is being proposed?

comment:8 Changed 4 years ago by liyang

Cc:… added

comment:9 Changed 3 years ago by schyler

I keep seeing people use -O2 -optlo -O3 when using -fllvm. Maybe this is worth taking a look at, if anything, just to bump up some base numbers and increase the llvm optimisation level in a more friendly way.

comment:10 Changed 3 years ago by carter

@schyler, who is doing that? -O3 on LLVM's opt has very version specific meaning, and (currently, according to discussions on the llvm-devs mailing list), has much less clear semantics than does -O3 in gcc. Do you have specific examples where llvm's O3 improves ghc code's perf? What LLVM version (please share).

its worth noting that generally on LLVM, many optimizations are in O3 to denote experimental / doesn't always work status, and then get promoted ot O1 / O2 when they have more robust code improvement characteristics

Note: See TracTickets for help on using tickets.