search for: vreg

...f -p 46985 > Password: > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > doveadm 46985 mrm cwd VDIR 22,2669215774 152 4 > /home/mrm > doveadm 46985 mrm rtd VDIR 19,766509061 28 4 / > doveadm 46985 mrm txt VREG 119,3584295129 1714125 182952 > /usr/local/bin/doveadm > doveadm 46985 mrm txt VREG 19,766509061 132272 14382 > /libexec/ld-elf.so.1 > doveadm 46985 mrm txt VREG 22,2669215774 6920 10680 > /home/mrm/mail/TRAVEL/.imap/hawaiian.airlines/dovecot.index...

According to man page, the only way it can return EINVAL (22) is either bad filter, or bad timeout. I can't see how the filter would be bad, so I'm guessing ts must be bad. Unfortunately I forgot to ask for it, so I am going to have to ask you run it again and run p ts if that's valid, then the only thing that can be bad if the file descriptor 23. Aki > On October 23, 2016 at

...honker.lerctr.org ~ $ sudo lsof -p 46985 Password: COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME doveadm 46985 mrm cwd VDIR 22,2669215774 152 4 /home/mrm doveadm 46985 mrm rtd VDIR 19,766509061 28 4 / doveadm 46985 mrm txt VREG 119,3584295129 1714125 182952 /usr/local/bin/doveadm doveadm 46985 mrm txt VREG 19,766509061 132272 14382 /libexec/ld-elf.so.1 doveadm 46985 mrm txt VREG 22,2669215774 6920 10680 /home/mrm/mail/TRAVEL/.imap/hawaiian.airlines/dovecot.index.log doveadm 46985 mrm...

...word: >> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >> doveadm 46985 mrm cwd VDIR 22,2669215774 152 4 >> /home/mrm >> doveadm 46985 mrm rtd VDIR 19,766509061 28 4 / >> doveadm 46985 mrm txt VREG 119,3584295129 1714125 182952 >> /usr/local/bin/doveadm >> doveadm 46985 mrm txt VREG 19,766509061 132272 14382 >> /libexec/ld-elf.so.1 >> doveadm 46985 mrm txt VREG 22,2669215774 6920 10680 >> /home/mrm/mail/TRAVEL/.imap/hawaiian.ai...

I have already written about something similar (either on the list, or in private communication), so this may look familiar. Here's a scenario I'm observing: First, we have some innocent looking code: vreg(32) = x // vreg(32) = 32-bit register ... = vreg(32) [...] vreg(64).low_half = vreg(32) // vreg(64) = 64-bit register [...] then, after register coalescing: vreg(64).low_half = x ... = vreg(64).low_half [...] [etc.] then, the live range of the 64-...

...lding the lock, which lock it > is waiting on (if any, marked with a *) and gdb that to work out what > is the matter with it, and perhaps why it is in that situation. Hmm... I have no lslocks on FreeBSD; will lsof do? In case, here's an excerpt: > samba 72462 root txt VREG 4,1302659313 430080 32007 /usr/jails/dc/var/db/samba4/private/secrets.tdb > samba 72462 root 46u VREG 4,1302659313 430080 32007 /usr/jails/dc/var/db/samba4/private/secrets.tdb > smbd 72466 root txt VREG 4,1302659313...

...OMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >>> doveadm 46985 mrm cwd VDIR 22,2669215774 152 4 >>> /home/mrm >>> doveadm 46985 mrm rtd VDIR 19,766509061 28 4 / >>> doveadm 46985 mrm txt VREG 119,3584295129 1714125 182952 >>> /usr/local/bin/doveadm >>> doveadm 46985 mrm txt VREG 19,766509061 132272 14382 >>> /libexec/ld-elf.so.1 >>> doveadm 46985 mrm txt VREG 22,2669215774 6920 10680 >>> /home/mrm/mail/TRAV...

On 2019-11-11 09:41, Andrew Bartlett wrote: >>> and what is the full backtrace on that tdbbackup? >> >> You mean: compile with debug symbols, attach gdb and get stack trace? >> If so, I'll do it, but I'll need some time. > > Yes, that's what I need. Please, find it below: (gdb) bt #0 0x0000000800fcdab8 in _fcntl () from /lib/libc.so.7 #1

...in/rsync -vaxH --delete --exclude-from=/tmp/fs_rsync.25232 / /mnt 2009-04-11 14:28:56 //mta02/home/mav6 @# lsof -p 25239,25242,25243 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME rsync-3.0 25239 root cwd VDIR 32,0 1024 2 / rsync-3.0 25239 root txt VREG 32,5 2906260 2350 /usr2/pge2/bin/rsync-3.0.5 rsync-3.0 25239 root txt VREG 32,0 867796 5746 /usr/lib/libc.so.1 rsync-3.0 25239 root txt VREG 32,0 35064 2903 /usr/lib/nss_files.so.1 rsync-3.0 25239 root txt VREG 32,0 744320 607...

...TYPE DEVICE SIZE/OFF NODE > NAME > >>> doveadm 46985 mrm cwd VDIR 22,2669215774 152 4 > >>> /home/mrm > >>> doveadm 46985 mrm rtd VDIR 19,766509061 28 4 / > >>> doveadm 46985 mrm txt VREG 119,3584295129 1714125 182952 > >>> /usr/local/bin/doveadm > >>> doveadm 46985 mrm txt VREG 19,766509061 132272 14382 > >>> /libexec/ld-elf.so.1 > >>> doveadm 46985 mrm txt VREG 22,2669215774 6920 10680 > >&gt...

...n a Reverse Post >> Ordering: >> >> >> - >> >> Canonical instruction ordering is done by moving a given instruction >> as close to the nearest use of its def as possible. >> >> >> >> - >> >> Next, canonical VReg renaming is done by building a collection of >> candidate instructions that can be thought of as sinks in the def-use >> graph: they are typically instructions that write to physical registers or >> store to memory. These candidates are used as the root of a breadth first...

...tof Parzyszek <kparzysz at codeaurora.org> wrote: > I have already written about something similar (either on the list, or in private communication), so this may look familiar. > > Here's a scenario I'm observing: > > First, we have some innocent looking code: > vreg(32) = x // vreg(32) = 32-bit register > ... = vreg(32) > [...] > vreg(64).low_half = vreg(32) // vreg(64) = 64-bit register > [...] > > then, after register coalescing: > vreg(64).low_half = x > ... = vreg(64).low_half > [...] > [etc....

...think of this as an open ended project. Techniques: Our prototype does the following for each basic block in a Reverse Post Ordering: - Canonical instruction ordering is done by moving a given instruction as close to the nearest use of its def as possible. - Next, canonical VReg renaming is done by building a collection of candidate instructions that can be thought of as sinks in the def-use graph: they are typically instructions that write to physical registers or store to memory. These candidates are used as the root of a breadth first walk over the vreg oper...

When we discussed this our line of thought was like this: - LLVM IR already uses %name for SSA values which is closer to what a vreg is than to what a physreg is. It would be neat to draw that parallel to llvm IR. - We wanted another sigil for physregs so they are easy to differentiate from vregs to allow people to differentiate vregs/physregs even if they don't know all the physreg names of a particular architecture. - The...

Hi A few of us have discussed enhancing the MIR vregs to include support for named-vregs. At the moment named regs are only supported for physical registers and number regs are reserved for vregs. We've decided that to properly implement a syntax for MIR named vregs we first need to reorganized the sigils used for physical registers and external...

On Mon, Jan 8, 2018 at 2:27 PM, Matthias Braun <mbraun at apple.com> wrote: > When we discussed this our line of thought was like this: > > - LLVM IR already uses %name for SSA values which is closer to what a vreg > is than to what a physreg is. It would be neat to draw that parallel to > llvm IR. > - We wanted another sigil for physregs so they are easy to differentiate > from vregs to allow people to differentiate vregs/physregs even if they > don't know all the physreg names of a partic...

Can we use %% for vregs? Seems slightly easier to remember %/%% than $/%. Also, %eax and $some_symbol are already familiar from typical assembly syntax and we probably don't want to break that association. It's all a bikeshed, but being more consistent with assembly is probably a win. -- Sean Silva On Dec 25,...

...gAlloc? > > This should definitely be done during regalloc. It seems that LiveIntervals will need to be taught about the new form of virtual registers. Hrm. I'm going to try to break this work up as much as possible. Also, do you see any problems with using the following class for vregs? It makes it possible to not have to go through and update every call site for a large number of functions. class vreg : public std::pair<unsigned,unsigned> { public: vreg(unsigned f) : std::pair<unsigned,unsigned>(f, 0) {} }; If this definition is OK, where should it live? It...

...g regalloc. > > It seems that LiveIntervals will need to be taught about the new form of > virtual registers. Hrm. I'm going to try to break this work up as much as > possible. Splitting up the work is good :) > Also, do you see any problems with using the following class for vregs? It > makes it possible to not have to go through and update every call site for a > large number of functions. > > class vreg : public std::pair<unsigned,unsigned> { > public: > vreg(unsigned f) : std::pair<unsigned,unsigned>(f, 0) {} > }; > > If this def...

> I think pseudo-instructions should also define isPseudo = 1 Ah yes, thank you. > I expect that before your custom inserter, the value produced by your pseudo instruction was in a vreg. You just have to reuse this vreg to put the result of your "stuff". > If you run llc with --print-before-all, you should be able to see the actual sequence. That's exactly my problem. How to know before my custom inserter where the produced value will be? I found some documentat...