However, it is possible that there will still be a problem if the C and C++ compiler have different int sizes, because the constant folding has to know the type at compile time, and thus we have to arbitrarily choose to use the C version. In future, we could perhaps swap all Ints for the appropriate substiution (e.g. Int64) at run-time, based on the flags and prior knowledge about C/C++ int sizes
One of these bugs is that array variables are counted as unused when they are used subscripted. I think that should be solved when we flip back to the listify approach.
The second bug is more interesting, as it is triggered only in a certain arrangement with an IF. It's either a bug in the flow-graph building or in the varsTouchedAfter code.
One of the tests fails at the moment because the specification node has two entries associated with it in the flowgraph. One is the scope-in and one is the scope-out. I think the analysis is currently picking the scope-out node and looking beyond that, where -- surprise, surprise -- the variable is not used again. So I need some easy way of telling the flow analyses which of the two nodes I want to start from, in this case and other ones where I also add two nodes related to the same point in the AST.
It used to just be the list of target type keys. It's now a map from
all possible type keys to a precomputed hit/through/miss decision for
them. gmapMFor can therefore dig into "through" types without needing
to (fail to) apply the generic function first.
This makes less difference than I was expecting: it shaves the time
for cgtest24 from 2m30 down to 2m15.
This is mostly straightforward: modify the parser to allow direction
decorators in the right places, and extend the type checker to match.
There's some slight awkwardness in that some of the Types functions
have to perform the same checks as the type checker (e.g. directing a
non-channel), so I've tidied up their error messages a bit.
At the backend, I've just added a little pass to strip out all the
DirectedVariables, since the other backend passes don't handle them
gracefully. From the occam/C point of view this is fine, but I'm not
sure if it's going to cause problems for C++.
All the passes now have their information (name, pre-requisites and post- properties) stored at the point where the pass is declared, which means the pass lists are just a simple list of pass functions.
The main consequence of this change was that the tests had to be changed. Now, instead of taking a "pass applied to data" item (type: PassM b), they take both the pass (type: Pass) and source data (type: b), and apply them later. This was the decision that involved the simplest changes to the existing tests (simply unbracketing the application of the pass to the source). I also had to include a few old-style versions though (testPass', testPassShouldFail') for where the functions were being used to test things that weren't actually passes (mainly StructureOccam).
Fixes#48
NameType is only really needed in the parser, so this takes it out of
NameDef, meaning that later passes defining names no longer need to
set an arbitrary NameType for them. The parser gets slightly more
complicated (because some productions now have to return a SpecType
and a NameType too), but lots of other code gets simpler.
The code that removed free names was the only thing outside the parser
using NameType, and it now makes a more sensible decision based on the
SpecType. Since unscoped names previously didn't have a SpecType at
all, I've added an Unscoped constructor to it and arranged matters
such that unscoped names now get a proper entry in csNames.
Fixes#61.
This makes it possible to mark a slice as not needing runtime
checking, which is immediately useful for _sizes arrays.
This fixes cgtest03, which was previously failing to compile because
the _sizes array for one of the constants in it contained a runtime
check and thus wasn't itself constant. I've added a testcase file for
the relevant bit of code.
This changes the Traversal API to the one that I've been working on in
the Polyplate branch, but implemented in terms of Data. The
performance isn't as good as the Polyplate version, but the code is a
lot simpler because it doesn't need all the type constraints (and it
doesn't make GHC struggle).
This also reworks all the passes in Tock to use the new API, including
those that previously used makeGeneric (which I've now removed) or
everywhereM. Most of the passes are simpler because of this, and I
suspect it's fixed a few subtle bugs resulting from missing recursion
in makeGeneric code.
I haven't yet profiled this, but subjectively it seems about the same
as the old Traversal (and thus faster for all the passes that didn't
yet use it).
This patch hides all the old typeOfExpression, typeOfName, typeOfVariable, etc, and unifies them into a single type-class with an "astTypeOf" function. The type-class is currently named Typed, but that can easily be changed (it's only explicitly referred to in the Types module). The patch is essentially the type-class with a giant find-and-replace on the other modules.
In particular, evalSimpleLiteral is now much nicer, and the error
messages should be a bit more comprehensible.
The signed types previously used a different version of fromRead that
passed an extra argument that it then didn't use; I've switched back to
the old version now, since it appears not to need it any more.
This makes sure that literals produced by the constant evaluator will never
contain UnknownDimension. The change looks a lot more complex than it really
is; it already carried the type "downwards", and most of this is just making it
carry it back up to where the A.Literal is being constructured.
This means you don't have to have folded constants throughout the tree/state in
order to evaluate them, which makes the early passes less awkward to manage.
The rendering code now takes the type it's aiming for, so it can produce a
value of exactly the same type as the expression that was being folded
originally (rather than trying to work it out for itself).
Subscripting Infer gives you Infer.
This also makes trivialSubscriptType handle user types in the same way as
subscriptType. (There probably isn't much reason to have both any more, since
subscriptType doesn't do the checks it used to do.)
It's redundant, since you can always compute them from the variable, and it
makes the code that deals with actuals rather cleaner.
On the other hand, it slightly complicates some of the tests, because any names
you use in an Actual need to be defined...
