Code optimization options

[jklmnn]

Context and Problem Statement

Optimizations of the generated code are currently done only in the generator. The problem here is that depending on the target and use case of the generated code different goals might be targeted. While some optimizations like removing unnecessary conversions are universally helpful others like inlining aspects are highly target and use case dependent.

Use Cases

The goal of this ticket is to provide a mechanism that allows the use to modify the optimization options of the generated code without modifying the generator itself. The scope of this ticket includes the ability to add compiler attributes via pragmas and/or aspects on a function/procedure level granularity. Modifications of the code structure and content itself are not part of this ticket.

As there are multiple different sets of options that can be combined I will split the considered options into the following scopes: features, granularity and syntax. For the location of these optimizations I'll consider the integration file unless there is a good second option.

Considered Feature Options

O1

Support only pragmas.

+ Pragmas are required as not all attributes can be expressed by aspects.
+ Consistent structure of generated optimization code.
− Inconsistent pragmas and aspects for the same subprogram possible.
− Less "modern" code.

O2

Support pragmas and aspects.

+ Full flexibility in terms of possible configuration.
+ More "modern" code.
− More effort required to implement both features.

Considered Granularity Options

O1

Specific function based approach. Each function must be declared specifically, even if it is the same function in different messages (e.g. Message_1.Verify and Message_2.Verify).

+ Very flexible.
+ No unclear definitions, e.g. for state procedures with equal names from different sessions.
− Possibly lots of boiler plate code.
− More complex integration into generator?

O1a

The same as O1 but with wildcards.

+ Same flexibility as O1.
+ Less verbose for similar functions of packages.
− Generator complexity?

O2

Only function names. Package names are not taken into account. E.g. setting an attribute for Verify would apply to all Verify procedures in all message packages. However a package annotation is required for session states.

+ Possibly sufficient flexibility unless e.g. Message_1.Verify requires different attributes than Message_2.Verify.
+ Less generator complexity?
− State procedures need to be handled separately.

O3

Preset of configurable functions/procedures. Only a specific set of procedures would be configurable. This would allow preconfigured subprograms, e.g. the setters that are already configured with Inline_Always. State procedures would be set as a specific feature that applies to all of them. Also small and very generic functions such as the type operators would be kept out.

+ Possibly sufficient flexibility.
+ Reduced generator complexity.
− Less flexible.
− Allowed subprograms need to be defined and checked.

Considered Syntax Options

O1

The optimizations are a separate dict value next to the session. It contains a dict of subprograms/features where each entry contains a list of pragmas. The list of pragmas is requires as some pragmas are valid if applied multiple times with different arguments, in particular pragma Machine_Attribute.

Optimization:
    Message_1.Verify:
      Machine_Attribute:
        - "flatten"
      No_Inline
    Message_2.Verify:
      Export:
        - C
        - "__message_2_verify"

+ Consistent with already existing formats
− Attributes without arguments may not work well?

So far I don't have a good alternative idea. I think there is still room for improvement here.

Decision Outcome

TBD