search for: resolverstate

...ik wrote: > On Sep 20, 2013, at 3:42 PM, Shankar Easwaran > <shankare at codeaurora.org> wrote: >> nextFile could pass the current resolver state at the time when its called, the linkingcontext can return the next file to be processed as below :- >> >> nextFile(currentResolverState) :- >> >> a) Returns the next file if the current node is not a group node >> b) Returns the next file in the group node, if the current node is a group node and the resolver state states undefined /weak / shared library atoms were added. >> c) Returns the start file in the...

...Shankar Easwaran >> <shankare at codeaurora.org> wrote: >>> nextFile could pass the current resolver state at the time when its >>> called, the linkingcontext can return the next file to be processed >>> as below :- >>> >>> nextFile(currentResolverState) :- >>> >>> a) Returns the next file if the current node is not a group node >>> b) Returns the next file in the group node, if the current node is a >>> group node and the resolver state states undefined /weak / shared >>> library atoms were added. &g...

...t;> <shankare at codeaurora.org> wrote: >>>> nextFile could pass the current resolver state at the time when its >>>> called, the linkingcontext can return the next file to be processed >>>> as below :- >>>> >>>> nextFile(currentResolverState) :- >>>> >>>> a) Returns the next file if the current node is not a group node >>>> b) Returns the next file in the group node, if the current node is >>>> a group node and the resolver state states undefined /weak / shared >>>> library...

...p provided any more content. On Sep 20, 2013, at 3:42 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > nextFile could pass the current resolver state at the time when its called, the linkingcontext can return the next file to be processed as below :- > > nextFile(currentResolverState) :- > > a) Returns the next file if the current node is not a group node > b) Returns the next file in the group node, if the current node is a group node and the resolver state states undefined /weak / shared library atoms were added. > c) Returns the start file in the group node, if...

Shankar and I discussed input file handling, and we came up with a design that may greatly simplify the input file handling, while giving more flexibility to developer to support complicated options, such as --{start,end}-group, -z rescan or -z rescan-now. It'd worth pursuing, so here's the idea: 1. We wouldn't probably want to let Resolver to handle the input graph directly, for we

...lazy mode, but it was fun to understand the lazy-stub code. Attached you will find a patch which follow your 1st option : a map Stub_address -> JITResolver instance, except that the used map is a "std::map" to apply the same upper_bound trick as in the map CallSiteToFunctionMap of the ResolverState. (If it is necessary for call_site -> function, this should be necessary for call_site -> resolver... Event if I'm not sure to master all subtle reasons - code alignment/prologue ?) A mutex on the StubToResolverMap should prevent any possible race conditions. Every object (Emitter, Resol...

...understand the > lazy-stub code. > > Attached you will find a patch which follow your 1st option : a map > Stub_address -> JITResolver instance, except that the used map is a > "std::map" to apply the same upper_bound trick as in the map > CallSiteToFunctionMap of the ResolverState. (If it is necessary for > call_site -> function, this should be necessary for call_site -> resolver... > Event if I'm not sure to master all subtle reasons - code alignment/prologue > ?) > A mutex on the StubToResolverMap should prevent any possible race > conditions. >...

...stub code. > > > > Attached you will find a patch which follow your 1st option : a map > > Stub_address -> JITResolver instance, except that the used map is a > > "std::map" to apply the same upper_bound trick as in the map > > CallSiteToFunctionMap of the ResolverState. (If it is necessary for > > call_site -> function, this should be necessary for call_site -> > resolver... > > Event if I'm not sure to master all subtle reasons - code > alignment/prologue > > ?) > > A mutex on the StubToResolverMap should prevent any possi...

...inal draft email had a parameter in nextFile(), but it seemed a little confusing because the information was referring to the previous file. That is, if the current resolver state has newDefinedAtoms, that really means the last file (returned by nextFile()) caused new atoms to be added. In your ResolverState you have bits for all the kinds of atoms added. Is all that needed? I think all the InputGraph needs to know is if the last file was used. A group is scanned repeatedly until there is one complete pass in which no new files were used. Also, is nextFile() going to be in InputGraph and directly...

In eager compilation mode, I don't know of anything that would go wrong with having multiple JITs in the process. However, in lazy compilation mode, we need to map stub addresses to the JIT that knows how to compile them. Right now, that's done by looking up the static "TheJITResolver" variable and assuming it's the only JIT, but we could 1) use a static

Hi everyone ! If I call ExecutionEngine::createJIT (or EngineBuilder::create) more than one time, the second time fails on a assertion "Multiple JIT resolvers?". It seems that the JIT is designed to be a singleton in the process, and I was wondering if it was something mandatory. How hard will it be to make it a non-singleton object ? Is this a JIT-only problem (work needed on JIT

...at codeaurora.org> wrote: >>>>> nextFile could pass the current resolver state at the time when >>>>> its called, the linkingcontext can return the next file to be >>>>> processed as below :- >>>>> >>>>> nextFile(currentResolverState) :- >>>>> >>>>> a) Returns the next file if the current node is not a group node >>>>> b) Returns the next file in the group node, if the current node is >>>>> a group node and the resolver state states undefined /weak / >>>>...