Opened 10 years ago

Closed 9 years ago

Last modified 9 years ago

#3208 closed defect (fixed)

default configuration for pre/post optimization modules

Reported by: Lennart Ochel Owned by: Lennart Ochel
Priority: high Milestone: 1.9.4
Component: Command Prompt Environment Version: trunk
Keywords: Cc:

Description

omc +help=preOptModules displays all available pre-optimisation modules. To take advantage of this feature, it is completely necessary to dump the default configuration. Otherwise, it is hopeless to figure out a working configuration.

It's the same for post-optimization of course.

Change History (18)

comment:1 by Martin Sjölund, 10 years ago

It would also be useful if it was possible to do -preOptModules-=xyz to simply remove xyz from the list of pre-optimizations. Or -preOptModules+=xyz to append xyz to the list of optimizations. Because this would work even if the default changes.

comment:2 by Lennart Ochel, 10 years ago

Ordering is essential, so it is not enough to just append the default configuration. But it would be good to have an easy to use option to disable a given module as you proposed.

comment:3 by Francesco Casella, 9 years ago

Milestone: Future1.9.4

comment:4 by Lennart Ochel, 9 years ago

Owner: changed from somebody to Lennart Ochel
Status: newaccepted

I added already the default values for preOptModules, postOptModules and initOptModules to the documentation/help page.

in reply to:  5 comment:6 by Lennart Ochel, 9 years ago

Replying to casella:

Just noticed that, see:

https://openmodelica.org/doc/OpenModelicaUsersGuide/latest/omchelptext.html

Yes, it is also available using omc +help=optmodules.

in reply to:  1 ; comment:7 by Lennart Ochel, 9 years ago

Replying to sjoelund.se:

It would also be useful if it was possible to do -preOptModules-=xyz to simply remove xyz from the list of pre-optimizations. Or -preOptModules+=xyz to append xyz to the list of optimizations. Because this would work even if the default changes.

I will add the functionality to easily enable/disable a specific pre-/post-optimization module.

in reply to:  7 comment:8 by Lennart Ochel, 9 years ago

Replying to lochel:

I will add the functionality to easily enable/disable a specific pre-/post-optimization module.

This pull request introduces a couple of new flags:

--forceRecommendedOrdering: This is a Boolean flag with default true. This flag means that the specified pre-/post-/init-optimization modules will be automatically arranged in the recommended order. This flag can be set to false to achieve the old behaviour.

--preOptModules+=module1,module2 / -–preOptModules-=module3,module4 : This activates/deactivates certain pre-optimization modules. Since the back end takes care of arranging all pre-optimization module properly, this cannot be used in combination with --forceRecommendedOrdering=false.
The same is implemented for post-/init-optimization phase. Therefore, the flags are called --postOptModules+=module1,module2 / -–postOptModules-=module3,module4 and --initOptModules+=module1,module2 / -–initOptModules-=module3,module4.

comment:9 by Lennart Ochel, 9 years ago

I am not that happy with the name forceRecommendedOrdering. It would be good to have a better name before the next release. However, I will push the changes now. If one has a proposal for a better name, then we could just change it.

comment:10 by Adrian Pop, 9 years ago

applyRecommendedOrdering or applyDefaultOrdering

in reply to:  10 ; comment:11 by Lennart Ochel, 9 years ago

Replying to adrpo:

applyRecommendedOrdering or applyDefaultOrdering

Thanks Adrian. More suggestions are still welcome. We can decide on the next OSMC Dev meeting how to finally call this.


Should the combination --preOptModules+=something –preOptModules-=something
a) trigger an error and abort translation or
b) trigger a warning which state that this is weird, disable (or enable?) something and continue translation?

in reply to:  11 ; comment:12 by Francesco Casella, 9 years ago

Replying to lochel:

Replying to adrpo:

applyRecommendedOrdering or applyDefaultOrdering

Thanks Adrian. More suggestions are still welcome. We can decide on the next OSMC Dev meeting how to finally call this.

The problem with these flag names is that it is not clear whose ordering they refer to.

What about --defaultOptModulesOrdering?

Should the combination --preOptModules+=something –preOptModules-=something
a) trigger an error and abort translation or
b) trigger a warning which state that this is weird, disable (or enable?) something and continue translation?

For me it should be an error. If a good soldier receives contradictory orders, it is none of his business to decide which one is the right one. Just stop and wait for new orders.

in reply to:  12 ; comment:13 by Martin Sjölund, 9 years ago

Replying to casella:

For me it should be an error. If a good soldier receives contradictory orders, it is none of his business to decide which one is the right one. Just stop and wait for new orders.

No. Latest orders are the ones you accept. Because they may have changed:

-d=gen,nogen

Simply means, set gen, then unset it. No problem.

--preOptModules+=something --preOptModules-=something

Means add something, remove something. No problem.

in reply to:  13 comment:14 by Francesco Casella, 9 years ago

Replying to sjoelund.se:

Replying to casella:
No. Latest orders are the ones you accept. Because they may have changed:

I have to admit I was exempted from military service back then. So I'm not really qualified here :)

Seriously, I agree with your point.

in reply to:  13 comment:15 by Lennart Ochel, 9 years ago

Replying to sjoelund.se:

No. Latest orders are the ones you accept. Because they may have changed:

Okay, now I have implemented it that way (see PR291).

comment:16 by Lennart Ochel, 9 years ago

Resolution: fixed
Status: acceptedclosed

comment:17 by Martin Sjölund, 9 years ago

Milestone: 1.9.41.9.4-1.9.x

Milestone renamed

comment:18 by Martin Sjölund, 9 years ago

Milestone: 1.9.4-1.9.x1.9.4

Milestone renamed

Note: See TracTickets for help on using tickets.