Re: mlton and llvm 3.7
Matthew Fluet <[email protected]> Mon, 7 Mar 2016 22:05:03 -0500
| Newsgroups | gmane.comp.lang.ml.mlton.user |
|---|---|
| Message-ID | <CAMrhFL6UcT77wr1xVEv-bB_FHxOznm2S3uF5Pzphmv=3v7kbhQ@mail.gmail.com> |
On Sun, Mar 6, 2016 at 2:26 PM, Chris Cannam <[email protected]> wrote: > > The LLVM codegen looks to be broken with LLVM 3.7. > > With 3.5: > > $ mlton > MLton ga3331b7 (built Sun Mar 6 19:13:15 GMT 2016 on chorizo) > $ llvm-as --version > LLVM (http://llvm.org/): > LLVM version 3.5.2 > Optimized build. > Built Dec 5 2015 (17:41:16). > Default target: x86_64-unknown-linux-gnu > Host CPU: core-avx2 > $ mlton -codegen llvm hello.sml > $ > > but with 3.7: > > $ mlton > MLton ga3331b7 (built Sun Mar 6 19:13:15 GMT 2016 on chorizo) > $ llvm-as --version > LLVM (http://llvm.org/): > LLVM version 3.7.1 > Optimized build. > Built Jan 15 2016 (15:55:32). > Default target: x86_64-unknown-linux-gnu > Host CPU: haswell > $ mlton -codegen llvm hello.sml > llvm-as: /tmp/fileTrLUL2.1.ll:229:25: error: expected comma after load's > type > %r0 = load %uintptr_t* @nextFun > ^ > call to system failed with exit status 1: > llvm-as -o /tmp/fileUQH4yM.as.bc /tmp/fileTrLUL2.1.ll > $ > > I'm pretty ignorant about LLVM and can't tell whether this is a big > problem or not -- looks like a small syntax detail but that might mask > something. Is anyone working on the LLVM back end? It appears to be backwards incompatible change made in LLVM 3.7. Compare http://llvm.org/releases/3.5.0/docs/LangRef.html#id157 and http://llvm.org/releases/3.7.0/docs/LangRef.html#id172 It is not explicitly mentioned in the 3.7 release notes, but is probably related to "LLVM IR and APIs are in a period of transition to aid in the removal of pointer types (the end goal being that pointers are typeless/opaque - void*, if you will). Some APIs and IR constructs have been modified to take explicit types that are currently checked to match the target type of their pre-existing pointer type operands. Further changes are still needed, but the more you can avoid using PointerType::getPointeeType, the easier the migration will be." (http://llvm.org/releases/3.7.0/docs/ReleaseNotes.html) I'm not sure the best resolution for MLton. I'm wary of introducing a "-llvm-version <major.minor>" option, which would appear difficult to implement correctly and maintain. Nobody is actively working on the LLVM codegen right now. I once started in on refactoring the LLVM codegen; there is a bit of cut-n-paste development that should be factored out. I also had a couple of other students look at updating the LLVM codegen, but it never got to a point that could be tested and merged. -- You received this message because you are subscribed to the Google Groups "MLton-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval