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