Start function flattening #1870
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is a very old (5+ years) rule that is much too naive in its handling of memory. We have better optimisations now, that aren't buggy.
Syntactic information does not belong in semantic objects.
Previously some parts of the compiler would use FilePaths directly, and it is ambiguous whether those refer to canonical import names. Now it should be clearer.
If this does not fix Windows, then I will remove it (again).
This is a breaking change, because until now we allowed functions like
def f (a: *[]i32, b: []i32) = ...
where we could then pass in a tuple where in an application `f (x,y)`
the value `x` would be consumed, but not `y`. However, this became
increasingly difficult to support as the language grew (and frankly,
it was always buggy). With this commit, the syntax above is still
permitted, but it is interpreted as
def f ((a,b): *([]i32, []i32)) = ...
i.e. the single tuple argument is consumed *as a whole*. Long term we
can also consider amending the syntax or warning about cases where it
is misleading, but that is less urgent.
I've wanted to make this simplification for a long time, but I always
hit various snags. Today I managed to make it work, and the next step
will be cleaning up the notion of "uniqueness" in return types as well
(it should be the more general notion of "aliases").
C compilers are (understandably) not smart enough to see that these are never actually used uninitialised.
This is a deviation from the concrete syntax, but humans tend to think of function calls having multiple arguments. Also, the AST had to keep a lot of useless metadata around to express the results of the intermediate applications. And again, it is related to making #1872 more feasible.
This mostly has the effect of making generated code a little neater.
Merge building of body statements and results for lifted functions. Will probably need to filter out existential size quantifiers before lifting results.
Remove existential quantifiers from the return type and result of a function before lifting as I believe their lifted version aren't needed.
This reverts commit d04ecc5. It might be useful later but for now it complicates things.
Lifting irregular parameters was (wrongly) in the order `[offsets, flags, segments, elements]`. When calling, the arguments were (rightly) given in the order `[segments, flags, offsets, elements]`.
Wrote too many elements in the final scatters.
…o flattening-functions
`inputReps` now also gives type information, which is used by `liftArg` to determine if free variables are regular or irregular.
Let scan functions (genScanomap, genScan, genExScan, ...) in the flatten builtins module operate on multi-dimensional arrays. Of note is that `exScanAndSum`, when given a single-dimensional array, will return the # of segments and sum of segment sizes as scalar values and when given a multi-dimensional array will return them as arrays. Also move `segMap` from Flatten.hs to Flatten.Builtins.hs
When passing flag and elems array to a function, or returning them from a function, resize them to please the type checker.
Move the common "if a subexp is a constant or free variable, replicate it, and otherwise do a lookup in dist inputs and dist env" code to a function `liftSubExp`. This is used in `liftArg`, `liftResult` and lifting match-expressions.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.