search for: numopt

...in (see process_plugin_option). >> >> What about that: >> >> $ grep ParseCommandLineOptions tools/gold/gold-plugin.cpp >> >> // ParseCommandLineOptions() expects argv[0] to be program name. >> Lazily >> >> cl::ParseCommandLineOptions(NumOpts, &options::extra[0]); > > > That is for the options that the gold plugin itself doesn't understand > and just passes to llvm. This allows you to do things like > --plugin-opt=-debug-pass=Arguments. This is what I expected, so my cl:opt should work, right? I don't real...

...his is an incorrect insertion, as the regs did in fact run out in this case. In setup(), the node is first put into not-provably-allocatables. However, one of it's neigbhour invoked handleDisconnectEdge(), and moves it into conservatively-allocatables, because DeniedOpts had become less than NumOpts (in isConservativelyAllocatable(). * There are lots of spillable nodes being popped before the one that can't be spilled. This seems intuitively wrong, as they are intervals that actually could be spilled. I would really appreciate some help and pointers on what might be going wrong here, J...

...s this is an incorrect insertion, as the regs did in fact run out in this case. In setup(), the node is first put into not-provably-allocatables. However, one of it’s neigbhour invoked handleDisconnectEdge(), and moves it into conservatively-allocatables, because DeniedOpts had become less than NumOpts (in isConservativelyAllocatable(). * There are lots of spillable nodes being popped before the one that can’t be spilled. This seems intuitively wrong, as they are intervals that actually could be spilled. I would really appreciate some help and pointers on what might be going wrong here,...

...ed. This is a description of what happened in my out-of-tree test case: applyR2() called on node N, which is overlapping Y and Z. The edges (N,Y) and (N,Z) are all-zeroes. Y and Z are overlapping and already have an interference edge. Z is just on the limit of not being conservatively allocatable: NumOpts is 8 and DeniedOpts is also 8. It is contained in NotProvablyAllocatableNodes. G.setEdgeCosts() is called and then the call stack grows with Solver->handleSetEdgeCosts(), handleRemoveEdge() into handleDisconnectEdge(), where NMd.handleRemoveEdge() is called, which decreases the DeniedOpts by on...

...ned in my out-of-tree test > case: > > > > applyR2() called on node N, which is overlapping Y and Z. The edges (N,Y) > and (N,Z) are all-zeroes. Y and Z are overlapping and already have an > interference edge. Z is just on the limit of not being conservatively > allocatable: NumOpts is 8 and DeniedOpts is also 8. It is contained in > NotProvablyAllocatableNodes. G.setEdgeCosts() is called and then the call > stack grows with Solver->handleSetEdgeCosts(), handleRemoveEdge() into > handleDisconnectEdge(), where NMd.handleRemoveEdge() is called, which > decreases...

...ion, as the regs did in fact run out in this > case. > > In setup(), the node is first put into not-provably-allocatables. > However, one of it’s neigbhour invoked handleDisconnectEdge(), and moves it > into conservatively-allocatables, because DeniedOpts had become less than > NumOpts (in isConservativelyAllocatable(). > > * There are lots of spillable nodes being popped before the one that can’t > be spilled. This seems intuitively wrong, as they are intervals that > actually could be spilled. > > > > I would really appreciate some help and pointers on...

...in gold, instead we parse the -plugin-opts that > gold passes the plugin (see process_plugin_option). > What about that: $ grep ParseCommandLineOptions tools/gold/gold-plugin.cpp // ParseCommandLineOptions () expects argv[0] to be program name. Lazily cl:: ParseCommandLineOptions (NumOpts, &options::extra[0]); -- Mehdi > > > On 30 May 2016 at 02:13, Mehdi Amini <mehdi.amini at apple.com> wrote: > > > > On May 29, 2016, at 5:44 PM, Shi, Steven <steven.shi at intel.com> wrote: > > > > (And I doubt the GNU linker supports LTO...

...>>> >>> What about that: >>> >>> $ grep ParseCommandLineOptions tools/gold/gold-plugin.cpp >>> >>> // ParseCommandLineOptions() expects argv[0] to be program name. >>> Lazily >>> >>> cl::ParseCommandLineOptions(NumOpts, &options::extra[0]); >> >> >> That is for the options that the gold plugin itself doesn't understand >> and just passes to llvm. This allows you to do things like >> --plugin-opt=-debug-pass=Arguments. > > This is what I expected, so my cl:opt should wo...

..., + noms=names(DataTest)[sapply(DataTest, + data.class)=="factor"])) -- Imputation 1 -- 1 2 Erreur dans am.inv(a = g11) : le mineur dominant d'ordre 22 n'est pas d?fini positif De plus : Warning message: In amcheck(x = x, m = m, idvars = numopts$idvars, priors = priors, : The number of catagories in one of the variables marked nominal has greater than 10 categories. Check nominal specification. Timing stopped at: 0.048 0 0.048 > Note : various repeats crashed at various points (one of tre trials started to simulate, and stopped...

> On May 29, 2016, at 5:44 PM, Shi, Steven <steven.shi at intel.com> wrote: > > (And I doubt the GNU linker supports LTO with LLVM). > [Steven]: I’ve pushed GNU Binutils ld to support LLVM gold plugin, see detail in this bug https://sourceware.org/bugzilla/show_bug.cgi?id=20070 <https://sourceware.org/bugzilla/show_bug.cgi?id=20070>. The new GNU ld linker works well with

We don't use cl::opt in gold, instead we parse the -plugin-opts that gold passes the plugin (see process_plugin_option). Cheers, Rafael On 30 May 2016 at 02:13, Mehdi Amini <mehdi.amini at apple.com> wrote: > > On May 29, 2016, at 5:44 PM, Shi, Steven <steven.shi at intel.com> wrote: > > (And I doubt the GNU linker supports LTO with LLVM). > [Steven]: I’ve pushed