Fix LLVM 3.9 build

[yuyichao]

Force LLVM to emit the code before we look for function addresses.

We call findSymbol right after we call addModule so this shouldn't make the JIT more eager than what it is now.

Fixes #15712

[vtjnash]

does this mean the CompileLayer had become lazy? our goal was definitely for this API to be eager since we do the lazy work outside of the JIT and only add it here when we need the fptr

[yuyichao]

That seems to be the case. I'm not sure when/how it happened since we only had this problem when using switching to our own symbol table.

[vtjnash]

i was assuming LocalSymbolTable would get populated sufficiently eagerly. but it seems it now first requires a lookup up for a symbol that needed be found in the object file for llvm to finalize the linking and relocations and call our finalization callback

[yuyichao]

I think so. But actually doing a symbol lookup may fall back to the O(n) scaling....

[vtjnash]

yes, this is better.

i suppose another option we could contribute upstream is to store a StringMap<ObjectLinkingLayer::ObjSetHandleT> created by ObjectLinkingLayer::addObjectSet (from walking the object file symbols). we could also mimic that by walking the module symbols before addModuleSet and create the same map using the return value from that call.

[yuyichao]

I imagine that can be useful if we want to rely on the lazyness of the OrcJIT itself at some point. IMHO doing that right now will just add one more lookup overhead since what we want is directly emitting the object file anyway...

[yuyichao]

Although in any case, I think we should report the O(n) scaling of symbol lookup assuming it haven't been fixed yet.