[llvm] r209007 - Fix most of PR10367.

[Nick Lewycky]

Owen Anderson wrote:
>
> On May 17, 2014, at 9:03 PM, Nick Lewycky <nicholas at mxc.ca
> <mailto:nicholas at mxc.ca>> wrote:
>
>>>
>>> I don’t see why. Your more restrictive representation is just going to
>>> arbitrarily limit the ability of frontends and backends to achieve things
>>> that your representation doesn’t realize are possible. LLVM IR should
>>> not be in the business of knowing what common object file formats
>>> are capable of expressing.
>>
>> On the contrary, that is precisely the plan (my plan). Why shouldn't it?
>
> Because LLVM is not (just) a C compiler. LLVM is used in lots of
> applications, particularly ones involving online compilation, that have
> no meaningful concept of a relocation, or have very different ideas of
> what the loader. Baking in more of the static C compilation model
> penalizes such use cases.

The idea is that the API only returns the constant relocations that the 
target supports. No relocations available means it returns nullptr and 
leaves your instructions alone. The main difference is that your 
bitcasts and inttoptr's stay in your instruction stream instead of being 
folded into constants. Alternatively, we could break those out of 
constant expr and keep the "just type changing" ones as non-relocation 
constants. Unless you had interesting ConstantExpr's that didn't lead to 
relocation emission, I don't think this breaks your use case.

Speaking of, didn't we just get rid of the JIT which did this? And the 
new way to JIT with LLVM is to produce a .o file in memory then dlopen 
it, either using your system dynamic loader or llvm's runtime dyld, 
whatever works?

Nick