Conversation
Initially, there are two options, -h for printing a help text and -w for requesting the initializer to be written to a data file. The latter option allows to omit this rather slow operation when not needed.
| main :: IO () | ||
| main = do args <- getArgs | ||
| let [modelFileName] = take 1 args -- First argument is file name | ||
| let (fs, nonOpts, errs) = getOpt RequireOrder optDescrs args |
There was a problem hiding this comment.
I think onnxToFeld should be viewed as a part of "Feldspar". With that perspective, it would make sense to have the pass options and everything else that the option handling in Feldspar implements. Can't we just add writeInits to the Options in Feldspar.Compiler.Options, and import most of the option handling logic from Feldspar.Compiler here?
(I realize this makes writeInits visible when just using the Feldspar library and the option wouldn't do anything useful there. I care less about that interface since it's not a user-facing interface.)
There was a problem hiding this comment.
The reason I want the plumbing in place from the beginning is that I'm scared, the plumbing has taken a lot of effort to bolt on afterwards in the library (and even with that effort, the result is still not great).
There was a problem hiding this comment.
I just added error checking to compileC in Plugin and started using that code in the RegressionTests instead of having duplicate code in the test suite for that. Can we get onnxToFeld to compile everything all the way to an executable by just ending main with:
compile opts ...
compileC opts cname oname []
?
There was a problem hiding this comment.
It would be more complicated than that, since onnxToFeld produces Faldpar source code, so you also need to run ghc on that and then run the resulting program with e.g. readProcessWithExitCode and then you could do compileC.
There was a problem hiding this comment.
Oh, one more level in the tower, and I think when running the resulting program is where compileC is called (perhaps by a regular pass using the pass manager?).
I assume I wasn't very clear, my suggestion for this patch was just to consolidate the option handling so we have one option handling to put us in a good position for taking the steps you outlined at a later time.
There was a problem hiding this comment.
I do not think onnxToFeld will ever need multiple passes, so the PassMgr is beside the point. Apart from that onnxToFeld currently has a '-h' option and might perhaps get a '-o' option or so in the future, but the bulk of its options will probably be specific to its function. Possibly we could have a layer on top of GetOpt dealing with common options; I think that would be better than using the same option type for onnxToFeld and Feldspar compiler.
There was a problem hiding this comment.
How do we pass --writeAfter FPUnASTF along to the compiled Feldspar program from inside onnxToFeld in the future?
2 participants
Initially, there are two options, -h for printing a help text
and -w for requesting the initializer to be written to a data
file. The latter option allows to omit this rather slow
operation when not needed.