search for: btr

...script/public-i libxapian.so.30.8.0 [.] GlassTable::get_exact_entry 3.19% script/public-i libc-2.28.so [.] __memcpy_ssse3 2.65% script/public-i libpthread-2.28.so [.] __libc_pread64 2.27% script/public-i [unknown] [k] 0xffffffff81800000 2.18% /mnt/btr/public perl [.] Perl_yyparse 2.11% /mnt/btr/public perl [.] Perl_yylex 1.92% script/public-i libxapian.so.30.8.0 [.] GlassPostList::move_forward_in_chunk_to_at_least 1.76% script/public-i libxapian.so.30.8.0 [.] GlassPostListTable::get_freqs...

Going back to the "prioritizing aggregated DBs" thread from February 2020, I've got 390 Xapian shards for 130 public inboxes I want to search against(*). There's more on the horizon (we're expecting tens of thousands of public inboxes). After bumping RLIMIT_NOFILE and running ->add_database a bunch, the actual queries seem to be taking ~30s (not good :x). Now I'm

1c54d77 (x86: partial unification of asm-x86/bitops.h, 2008-01-30) changed a bunch of btrl/btsl instructions to btr/bts, with the following justification: The inline assembly for the bit operations has been changed to remove explicit sizing hints on the instructions, so the assembler will pick the appropriate instruction forms depending on the architecture and the context. Unf...

(resent without HTML) On 07/14/2013 05:56 AM, Ramkumar Ramachandra wrote: > 1c54d77 (x86: partial unification of asm-x86/bitops.h, 2008-01-30) > changed a bunch of btrl/btsl instructions to btr/bts, with the following > justification: > > The inline assembly for the bit operations has been changed to remove > explicit sizing hints on the instructions, so the assembler will pick > the appropriate instruction forms depending on the architecture...

...mnemonics? Where are the authoritative instruction set pages? If such a thing were readily available, why are there gaps in the current implementation? A quick Googling gets me [1], but I can't say it's authoritative. What's important is that there certainly are architectures where btr/bts are valid instructions, and they must be supported. btr/bts are certainly not invalid instructions that we're bending over backwards to support, because linux.git/gas works with them. [1]: http://web.itu.edu.tr/kesgin/mul06/intel/index.html

On Wednesday 10 July 2013 22:18:23 Jevin Sweval wrote: > http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/arch/x86/include/ > asm/bitops.h#L68 > > Here is one example that I found. Are the inline assembly arguments > ambiguous in size? It would help us for sure to build the kernel and others. -- JS

On Wed, Jul 10, 2013 at 12:29 PM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > The instructions btr and bts are perfectly valid, and have existed since > Intel 386. GNU as supports them fine. Unfortunately, LLVM does not > support them, and barfs with: > > error: ambiguous instructions require an explicit suffix > > Fix this problem by disambiguating it correctly, following...

Jim Grosbach wrote: > Also, please elaborate on why this is a good change. Because gas accepts it > isn’t sufficient reason in and of itself. That they're valid instructions isn't sufficient reason? Should I additionally say that linux.git uses them? I wrote: > The instructions btr and bts are perfectly valid, and have existed since > Intel 386.

...a good change. Because gas accepts it isn’t sufficient reason in and of itself. -Jim On Jul 10, 2013, at 1:18 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Jul 10, 2013 at 12:29 PM, Ramkumar Ramachandra > <artagnon at gmail.com> wrote: >> The instructions btr and bts are perfectly valid, and have existed since >> Intel 386. GNU as supports them fine. Unfortunately, LLVM does not >> support them, and barfs with: >> >> error: ambiguous instructions require an explicit suffix >> >> Fix this problem by disambiguating...

...re the authoritative instruction set pages? If such a thing > were readily available, why are there gaps in the current > implementation? A quick Googling gets me [1], but I can't say it's > authoritative. What's important is that there certainly are > architectures where btr/bts are valid instructions, and they must be > supported. btr/bts are certainly not invalid instructions that we're > bending over backwards to support, because linux.git/gas works with > them. > > [1]: http://web.itu.edu.tr/kesgin/mul06/intel/index.html > _ The correct answ...

Hi, I happened to notice that linux.git uses plenty of btr and bts instructions (not btrl, btrw, btsl, btsw). For examples, see arch/x86/include/asm/bitops.h. LLVM barfs on these due to ambiguity, while GNU as is fine with them. Surely, there must be architectures where the w/l variant is unavailable? LLVM must support those architectures, no? Thanks.

...ving correctly according the the documented Intel assembly mnemonics? If the former, the fix belongs in the project, not the assembler. If the latter, then we should absolutely fix the assembler. From your emails, it is unclear to me which is the case. -Jim > I wrote: >> The instructions btr and bts are perfectly valid, and have existed since >> Intel 386. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130710/4f50d063/attachment.html>

Jim Grosbach wrote: > That does raise a clarifying question here. Is the code you’re interested in > using Intel or AT&T syntax? > > Also note that the question isn’t whether we should support the btr/bts > instructions. We absolutely must (and do). The question is whether we are > properly handling the un-suffixed mnemonic form of the assembly syntax. > > Perhaps you can help by clarifying via explicit example what code you > believe should work but does that. Descriptions are gr...

could you please send me a copy of the btr driver/kernel?NrybXǧv^)޺{.n+{n߲)w*jgݢj/zޖ2ޙ&)ߡaGhj:+vw٥

Stephen Checkoway wrote: > [...] Thanks for the absolutely splendid analysis! > For the memory, immediate form without the suffix, it seems like the options are > 1. If the immediate value is in [0,15], use btsl/btrl since it saves a byte, otherwise error; > 2. Follow both gas's behavior and the Solaris assembler manual Jim Grosbach linked to which stated that unsuffixed instructions are assumed to be long and alias bts to btsl and btr to btrl; or > 3. Always error even when there is no ambiguity. &g...

...e used. In contrast, bts m16,r16 (btsw) and bts m32,r32 (btsl) are identical for bit offset operands in [0,63] and are likely identical for [-2^{15}, 2^{15}-1], although I didn't actually check the others. See the attached reg.c which changes the immediate constraints to register constraints. btr behaves similarly. For the memory, immediate form without the suffix, it seems like the options are 1. If the immediate value is in [0,15], use btsl/btrl since it saves a byte, otherwise error; 2. Follow both gas's behavior and the Solaris assembler manual Jim Grosbach linked to which stated t...

...tive instruction set pages? If such a thing >> were readily available, why are there gaps in the current >> implementation? A quick Googling gets me [1], but I can't say it's >> authoritative. What's important is that there certainly are >> architectures where btr/bts are valid instructions, and they must be >> supported. btr/bts are certainly not invalid instructions that we're >> bending over backwards to support, because linux.git/gas works with >> them. >> >> [1]: http://web.itu.edu.tr/kesgin/mul06/intel/index.html &gt...

...mnemonics? Where are the authoritative instruction set pages? If such a thing were readily available, why are there gaps in the current implementation? A quick Googling gets me [1], but I can't say it's authoritative. What's important is that there certainly are architectures where btr/bts are valid instructions, and they must be supported. btr/bts are certainly not invalid instructions that we're bending over backwards to support, because linux.git/gas works with them. [1]: http://web.itu.edu.tr/kesgin/mul06/intel/index.html _ The correct answer here is "Vol 2a of t...

On Wed, Jul 10, 2013 at 11:12 AM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > Hi, > > I happened to notice that linux.git uses plenty of btr and bts > instructions (not btrl, btrw, btsl, btsw). For examples, see > arch/x86/include/asm/bitops.h. LLVM barfs on these due to ambiguity, > while GNU as is fine with them. Surely, there must be architectures > where the w/l variant is unavailable? Both variants have existed sinc...

...##################################################### where.is.X <- function() { nx <- 3 ny <- 4 y <- as.factor(c(1,0,1,1)) X <- data.frame(matrix(c(1:(nx*ny)), nrow = ny, ncol = nx, dimnames=list(c(),paste("x",1:nx,sep="")))) btr <- best.tree.lost(y~., X) print(summary(btr)) } best.tree.lost <- function (fmla, X) { tr <- tree(fmla, X) print(summary(tr)) cvtr <- cv.tree(tr, envir=parent.frame()) size <- cvtr$size[order(cvtr$dev)[1]] print(size) btr <- prune.tree(tr, best=size) btr } ####...