[llvm] r206228 - [ARM64][MC] Set the default CPU string to generic.

[Eric Christopher]

>
> This is patently false except for the single cpu that changed.

(On a separate note it seems that Mail is being weird about quoting,
it works sometimes, it doesn't otherwise, anyhow :)...

>
> I think it would be useful if you were more specific about what is false
> about the above statement.  I think this is worth clearing up.

Fair enough.

>
> The MCJIT doesn't require the module to have a target set, and it doesn't
> require the caller to set the target of the ExecutionEngine.  It also
> doesn't require the client to set Arch or CPU.  This is true both in the C
> and C++ APIs.  EngineBuilder will set these things for you to sensible
> defaults on all platforms *except* ARM64, where things get murky.  For
> example on X86, even if you don't explicitly set the CPU the MCJIT will
> figure out what CPU you're running on along with all of its relevant
> features (whether it has AVX, etc) and it will generate code accordingly.
> Also, the C API currently only lets you set the target on the module, not
> the ExecutionEngine, and so this prevents you from setting the Arch+CPU.
>
> The MCJIT has explicit code to set the target/CPU/etc to a sensible default
> that is appropriate for JITing code into the process in which the JIT itself
> runs.

Actually, it'll use the module if you don't set anything:

TargetMachine *EngineBuilder::selectTarget() {
  Triple TT;

  // MCJIT can generate code for remote targets, but the old JIT and Interpreter
  // must use the host architecture.
  if (UseMCJIT && WhichEngine != EngineKind::Interpreter && M)
    TT.setTriple(M->getTargetTriple());

  return selectTarget(TT, MArch, MCPU, MAttrs);
}

which seems to be what you'd want? I'm not sure in your use case how
things aren't working out. The backend code now looks the same for
both X86, arm, and arm64 so why it's failing should probably be looked
at. This change merely exposed something else.

> It would be useful if you were more specific about what you think is false
> about any of this.

^ :)

>
> Anyway, I would be against any change to the C API that would require JIT
> clients to set the CPU, Arch, or target triple as a prerequisite to using
> the MCJIT.  This would be a breaking change to stable API and the MCJIT
> should continue to do as it always did: target the host by default.
>

Agreed. (I know this suprises you).

> It's only stable between releases. Anything else is anything goes. As
> I don't believe it was in 3.4...
>
> MCJIT C API was in 3.4.
>

All of it or parts? Either way, good to know.

-eric