search for: discriminators

...// discriminator: 0x40 } if (i++ < N) { foo(); // discriminator: 0x100 if (i++ < N) { foo(); // discriminator: 0x200 if (i++ < N) { foo(); // discriminator: 0x300 } } } The cost of this change would be increased debug_line size because: 1. we are recording more discriminators 2. discriminators become larger and will take more ULEB128 encoding. The benefit is that the sample pgo profile can accurately represent the code execution frequency. And we do not need to introduce new building blocks to debug info. Comments? Thanks, Dehao -------------- next part -------------...

...loading this profile, we will recompute the branch probability and hopefully improve the optimization quality for that target pass. The flow sensitivity in the profile is through a hierarchical discriminator scheme that can better preserve flow information in the Perf profile. 2.1. Current Use of Discriminators The AFDO profile contains a discriminator field whose goal is to differentiate statements with the same line number in the source code (largely from MACRO expansions). Discriminators were later expanded to get more accurate profile counts. It is expanded to 3 components which can partially addre...

...if (i++ < N) { >> foo(); // discriminator: 0x200 >> if (i++ < N) { >> foo(); // discriminator: 0x300 >> } >> } >> } >> >> The cost of this change would be increased debug_line size because: 1. we >> are recording more discriminators 2. discriminators become larger and will >> take more ULEB128 encoding. >> >> The benefit is that the sample pgo profile can accurately represent the >> code execution frequency. And we do not need to introduce new building >> blocks to debug info. >> >> Co...

...(); // discriminator: 0x100 > if (i++ < N) { > foo(); // discriminator: 0x200 > if (i++ < N) { > foo(); // discriminator: 0x300 > } > } > } > > The cost of this change would be increased debug_line size because: 1. we > are recording more discriminators 2. discriminators become larger and will > take more ULEB128 encoding. > > The benefit is that the sample pgo profile can accurately represent the > code execution frequency. And we do not need to introduce new building > blocks to debug info. > > Comments? > > Thanks, &g...

...(); // discriminator: 0x100 > if (i++ < N) { > foo(); // discriminator: 0x200 > if (i++ < N) { > foo(); // discriminator: 0x300 > } > } > } > > The cost of this change would be increased debug_line size because: 1. we > are recording more discriminators 2. discriminators become larger and will > take more ULEB128 encoding. > > The benefit is that the sample pgo profile can accurately represent the > code execution frequency. And we do not need to introduce new building > blocks to debug info. > > Comments? > > Thanks, &g...

Hello everyone, I am totally new to the R program. I have had a look at some pdf documents that I downloaded and that explain how to do many things in R; however, I still cannot figure out how to do what I want to do, which is to perform Discriminant Correspondence Analysis on a rectangular matrix of data that I have in an Excel file. I know R users frown upon Excel and recommend converting Excel

...foo(); // discriminator: 0x200 >>> if (i++ < N) { >>> foo(); // discriminator: 0x300 >>> } >>> } >>> } >>> >>> The cost of this change would be increased debug_line size because: 1. >>> we are recording more discriminators 2. discriminators become larger and >>> will take more ULEB128 encoding. >>> >>> The benefit is that the sample pgo profile can accurately represent the >>> code execution frequency. And we do not need to introduce new building >>> blocks to debug info....

...< N) { > foo(); // discriminator: 0x100 > if (i++ < N) { > foo(); // discriminator: 0x200 > if (i++ < N) { > foo(); // discriminator: 0x300 > } > } > } > > > The cost of this change would be increased debug_line size because: > 1. we are recording more discriminators 2. discriminators become > larger and will take more ULEB128 encoding. > > > The benefit is that the sample pgo profile can accurately represent > the code execution frequency. And we do not need to introduce new > building blocks to debug info. > > > Comments? >...

...ading this profile, we will recompute the branch probability and hopefully improve the optimization quality for that target pass. The flow sensitivity in the profile is through a hierarchical discriminator scheme that can better preserve flow information in the Perf profile. 2.1. Current Use of Discriminators The AFDO profile contains a discriminator field whose goal is to differentiate statements with the same line number in the source code (largely from MACRO expansions). Discriminators were later expanded to get more accurate profile counts. It is expanded to 3 components which can partially addr...

...0 foo(); // discriminator: 0x40 foo(); // discriminator: 0x40 } if (i++ < N) { foo(); // discriminator: 0x100 if (i++ < N) { foo(); // discriminator: 0x200 if (i++ < N) { foo(); // discriminator: 0x300 } } } If we allocate 8 bits to "traditional" discriminators, then 0x40 falls into that range, so I'd think the calls to foo() inside the loop should be using 0x400 to encode the unroll factor. Note this requires 2 bytes for ULEB128 instead of 1. And if we allocate another 8 bits to the unroll factor, then the trailing calls should use 0x10000, 0x20000,...

...t; > foo(); // discriminator: 0x300 > > > > } > > > > } > > > > } > > > > > > > > > > > > The cost of this change would be increased debug_line size > > > because: > > > > 1. we are recording more discriminators 2. discriminators become > > > > larger and will take more ULEB128 encoding. > > > > > > > > > > > > The benefit is that the sample pgo profile can accurately > > > represent > > > > the code execution frequency. And we do no...

...(i++ < N) { > foo(); // discriminator: 0x70000 > } > } > } > I think my method can save discriminator space because all clones > share the same discriminator. Consider that if a loop is unrolled > 100 times, then with your algorithm, we may end up having 100 > different discriminators, which seem not good for debug info size. > > > > -Hal > > > > > > > > > > > > > The goal of the proposed change, is to make profile more > > > > > > > accurately > > > > > > > represent the attribute o...

Dear All This is more of a statistics question than a question about help for R, so forgive me. I am using lda from the MASS package to perform linear discriminant function analysis. I have 14 cases belonging to two groups and have measured each of 37 variables. I want to find those variables that best discriminate between the two groups, and I want to visualise that and create a

...scriminator: 0x70000 >> } >> } >> } >> >> I think my method can save discriminator space because all clones share >> the same discriminator. Consider that if a loop is unrolled 100 times, then >> with your algorithm, we may end up having 100 different discriminators, >> which seem not good for debug info size. >> >>> >>> >>> >>>> >>>> >>>> -Hal >>>> >>>> >>>>> The goal of the proposed change, is to make profile more accurately >>>>>...

...bution is inherently ambiguous. In those cases, I have no problem with Just Doing It. Something likely to pad the line table to benefit profiling without similarly benefiting debugging… that's probably worth inventing a –gprofile or some such. I suspect Dehao's more elaborate ideas about discriminators fall into that category (although IIRC discriminators were invented mainly to benefit profiling in the first place, so maybe having discriminators at all would be something to put under a –gprofile kind of option). --paulr From: David Blaikie [mailto:dblaikie at gmail.com] Sent: Monday, November 2...

...t; > > > > > > > > > > > > > > > > > > > > > > > The cost of this change would be increased debug_line size > > > > > because: > > > > > > > > > > > 1. we are recording more discriminators 2. discriminators > > > > > become > > > > > > > > > > > larger and will take more ULEB128 encoding. > > > > > > > > > > > > > > > > > > > > > > > > > > > >...

Hi everyone, I'm trying to solve a problem about how to get the Fisher's discriminant functions of a "lda" (linear discriminant analysis) object, I mean, the object obtained from doing "lda(formula, data)" function of the package MASS in R-project. This object gives me the canonical linear functions (n-1 coefficients matrix of n groups at least), and only with this

...individual-discriminator counts mapped to which actual blocks, and then make some kind of decision about whether to do the transform differently based on that information. Then, if the optimization did choose to do the transform differently, then that leaves the IR in a state where the individual discriminators *cannot* map back to it. (Say you unroll by 2 instead of 4; then you have only 1 trailing copy, not 3, and a discriminator that maps to the second trailing copy now maps to nothing. The individual-discriminator data becomes useless.) Am I expressing this well enough to show that what Hal is look...

...; > > > the > > > > > > > > transform differently, then that leaves the IR in a > > > > > > > > state > > > > > > > > where > > > > > > > > the > > > > > > > > individual discriminators *cannot* map back to it. (Say > > > > > > > > you > > > > > > > > unroll > > > > > > > > by 2 instead of 4; then you have only 1 trailing copy, > > > > > > > > not > > > > > > > >...

On Jan 1, 2009, at 6:25 AM, Jon Harrop wrote: >> Exactly. I'm not especially interested in C-style unions, I'm >> interested >> in discriminated unions. But the actual discriminator field is easily >> represented in LLVM IR already, so there's no need to extend the IR >> to >> support them. That's why I am only asking for C-style union