Ignore:
Timestamp:
Apr 17, 2025, 10:06:15 PM (5 months ago)
Author:
Peter A. Buhr <pabuhr@…>
Branches:
master
Children:
15eebd4
Parents:
3c1e432 (diff), 471613c (diff)
Note: this is a merge changeset, the changes displayed below correspond to the merge itself.
Use the (diff) links above to see all the changes relative to each parent.
git-author:
Peter A. Buhr <pabuhr@…> (04/17/25 21:52:02)
git-committer:
Peter A. Buhr <pabuhr@…> (04/17/25 22:06:15)
Message:

Merge branch 'master' of plg.uwaterloo.ca:software/cfa/cfa-cc

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/proposals/autogen.md

    r3c1e432 r7a43045  
    156156### Earlier Inline of Autogenerated Function
    157157A warning that comes up around autogenerated functions mentions static function called from inline functions. Although, this may not lead to problems, it does highlight some issues with the C initializer to Cforall constructor conversion.
     158
     159# Possible Solution and Suggestions
     160Proposals for features to address some of the above issues.
     161
     162## Fine-Grained C Constructor Escapes
     163Currently, the C escape for constructors only work at the top constructor. This suggestion moves the escape from the initialization context to the constructor call/initializer. (As an aside, ideally there would be no need for a C escape because Cforall would never overstep, but until then, we should try to have good escapes.)
     164
     165There are two ways to escape an constructor, so that Cforall always resolves it as a C initializer and not a Cforall constructor call. These are syntactically tied to the initialization context, not the initializer, and semantically apply to the top initializer.
     166
     167The syntax change could just move the `@` from the declaration to the initializer. Escaped initializers are written `@{ ... }`. This doesn't change the syntax for compound literals (`(TYPE)@{ ... }`), but it does change variable declarations (`DECL @= { ... };` becomes `DECL = @{ ... };`). Each escape means exactly that initializer must not be a constructor call.
     168
     169## Initializer/Constructor
     170A different way to stop Cforall constructors from conflicting C initializers they could just use a different syntax. This could try to be a small change to the initializer syntax, the minimum change to separate the two, or a more drastic change, that might enable new features (ex. `ctor_name{ ... }`, allowing for named constructors).
     171
     172This fixes the backwards compatibility issue, and removes the need for escapes, but does result in a larger syntax change for new calls. Separating initializers from constructors might also help with autogeneration and unexpected conflicts between autogen and manually defined functions.
     173
     174## Autogeneration Attributes
     175Add attributes that control what routines are autogenerated. At its simplest `[[cfa_no_autogen]]` could be added to a SUE declaration to prevent any autogenerated routines. That could be it, but it does require manually define any functions that would be autogenerated routines, so you could have more selective attributes (or a single attribute with options) to disable only the autogeneration of particular routines.
     176
     177## The is_pod Assertion (Optimization)
     178An assertion that a type is a "plain old data" type. A plain old data type is any type that is entirely defined by its bit pattern without any context used in its definition.
     179
     180This means:
     181+   Destroying an instance of the type is a no-op, no clean-up required.
     182+   Copying the type replicates the bit pattern in the new memory location.
     183+   Moving the type is equivalent to copying the type.
     184
     185This means that the type carries size and alignment, and from that you can implement the copy constructor, copy assignment and destructor using just memory operations. That means this is equivalent to `is_value` in terms of operations but the implementations of those functions can be different, and less data has to be passed around.
     186
     187One requirement that is not used is that all zeros a valid bit pattern for that type (or that and given bit pattern is valid). It could be added, and then you can also construct instances of the type by zero filling the storage. It is a `is_object` interface and considering the trend to from object to value, right now it seems it should at most be a secondary trait/assertion (ex. `is_pod0`).
     188
     189However, in both of these cases there is actually no new functionality added. These are existing operations. The advantage is it allows for more optimizations to be used. The function pointers do not need to be passed into polymorphic functions and some operations can be bundled together. Whether these optimizations save significant about of time or memory has to be investigated.
Note: See TracChangeset for help on using the changeset viewer.