[llvm] r209007 - Fix most of PR10367.
nicholas at mxc.ca
Sun May 18 02:20:59 PDT 2014
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,
More information about the llvm-commits