Allow setting aggressive-conditions per rule

[yannickl96]

Hi,

currently the compiler allows to set -aggressive-conditions on a per-module basis by setting the (* options="-aggressive-conditions" *) attribute above the module. Would it be possible to extend the mechanism to a per-rule basis?
E.g., I may have one rule where the conservative CAN_FIRE computation (just lift every implicit guard into the rule condition) may be sufficient and -aggressive-conditions would create an overly complicated schedule and another one where -aggressive-conditions generates a better schedule, allowing a rule to fire more frequently/keep the code cleaner/etc. For that scenario, having the possibility to tell the compiler to compute the firing condition differently for just a specific rule may be quite useful.
Or did I miss an existing option for that behavior somewhere?

Best,
Yannick

[quark17]

There is an attribute aggressive_implicit_conditions that can be place on rules. I see that it is not documented in the BSV user guide and the BSC parser considers it to be a "hidden" attribute -- in error messages about unrecognized attributes, BSC will list the accepted attributes, but will only list the "visible" attributes and not the "hidden" ones.

There is also an attribute conservative_implicit_conditions that works in the opposite direction.

I don't believe there's a reason to avoid aggressive-conditions, so I suggest always providing the flag to BSC (and think we should make it the default). But if you have a particular reason to be concerned about "overly complicated schedules", I'd be interested to know more.

The question of the default behavior of BSC came up on the mailing list recently (in this thread). And I see that I already posted about these hidden attributes, in this thread from a few years ago.

Unfortunately, this attribute is not supported on methods, and Issue #470 has been opened for that. I think it might also be useful to specify this on specific conditions, as well -- or maybe on the action? That could be supported by the parser, or a primitive function could be used -- like aggressiveIf or conservativeIf, say.

[yannickl96]

Thanks as always for the elaborate reply. I will try to come up with a minimal example showcasing the "overly complicated schedules". I am not sure what the best granularity is that BSV should support as the code may become horrible to read if we scatter attributes left and right to work around the fundamental execution model.

I will provide my example on the mailing list thread, so it is in one place with the discussion. Feel free to close the issue.

Best,
Yannick