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

[Filip Pizlo]

On April 25, 2014 at 12:16:05 PM, Eric Christopher (echristo at gmail.com) wrote:

> 
> 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? 
If you don't set the target on the module, then it gets the process triple.  Hence, you get target := host if your code never says anything about the target triple in either the module creation or MCJIT initialization.

And that's probably a good thing since currently the LLVM C API doesn't expose getting the process triple, so if we required C API clients to set the target triple without giving them a way of getting the right one, then the whole C API would become a kind of cruel joke.

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. 
I'm not totally clear on what the deal is on ARM64 other than things get murky because not all of the bits in MCJIT and elsewhere know that CPU/Arch/Attrs are things that should be inferred to match the host, and failing to set those things causes weirdness.  I'm annoyed that it went from "works for me" to "busted for me" but I'm not interested in pushing that point further.

To me the purpose of this thread is to try to establish protocol for changes that affect MCJIT going forward.  It's good that you agree that the MCJIT C API shouldn't require the client to ever set the CPU/Attrs/Arch as a prerequisite to using it and that we shouldn't change the API to require that.  I also think that we should continue to allow the client to not even set the target on the module, allowing MCJIT to infer it to be the process triple.  That should all Just Work.



> 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. 
Basically all.  There were changes since then to clean things up in a non-breaking way, like adding enums for some of the gnarly C function types in the memory management callbacks.

-Filip





-eric 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140425/d28c8988/attachment.html>