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

Eric Christopher echristo at gmail.com
Fri Apr 25 13:07:25 PDT 2014

> 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.

It kinda is anyways, but your point is fair :)

> 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.

Annoyance is perfectly legitimate.

> 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.

I think if you want something more than "the most generic code for a
target" we might require something. Or else go the llvm::sys:: way of
grabbing the current target in MCJIT which to me makes more sense.
I.e. detect and use everything about the target at process startup if
there's no default given (remote jitting being a separate problem, but
you should be required to pass everything in that case). Going to
bring in Jim here on the discussion since he's the authority on MCJIT.

> 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.

Cool deal.


More information about the llvm-commits mailing list