search for: 20200331

Looking at the Opus comparison page[1], I can't figure out whether the Opus/AAC/Vorbis/MP3 lines are meant to imply a mono or stereo encoding. Could someone please update the caption to clarify this? The single dot for G.711 is clearly mono, but for stereo music, are the codecs at the top meant to converge near 128 kbps, or 256 kbps? [1] http://opus-codec.org/comparison/

Hi all, Recently I've had some extra time on my hands, so I spent part of the weekend coding up a simple chrome extension to monitor the status of code reviews on the LLVM phabricator instance. This extension is inspired by some other review monitoring tools that I've used in the past. It allows for monitoring revisions that a user needs to review, revisions by the user that need to be

...__________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200331/6430b58b/attachment.html>

On 31/03/2020 18:29, Adrian Prantl via llvm-dev wrote: > It's great to see someone interested in improving yaml2obj! > > As far as I'm concerned, the main problem with yam2obj for DWARF testcases is that at the moment, it is both too high-level and too low-level at the same time. For writing debug info testcases, yaml2obj at the moment does not add anything on top of assembler.

I am interested in being able to encode a single Opus stream using several CPU cores. I get a raw audio input and "opusenc" can transcode it at 1200% speed (Raspberry PI 3B+). It saturates a single CPU core, but the other three are idle. Is out there any project to add multithreading options to "opusenc", or something in that line? Looking around, I have found this:

...ARF DIE assembler directives be a more useful abstraction level? If you think about the .loc directive, there is actually some prior art in assembler. -- adrian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200331/01490860/attachment.html>

...was shocked by how well it kept up with 40 callers. I am trying to figure out how scalable it is on VPS's vs using bare metal. TIA. Regards, Dovid -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20200331/196310e2/attachment.html>

...[1] http://opus-codec.org/comparison/ _______________________________________________ opus mailing list opus at xiph.org http://lists.xiph.org/mailman/listinfo/opus -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/opus/attachments/20200331/94807527/attachment.html>

>>> Ralph Giles <giles at thaumas.net> schrieb am 30.03.2020 um 23:17 in Nachricht <11930_1585603054_5E8261ED_11930_50_1_c110a52d-de95-3bbb-35b2-eca12c79f143 at thaum s.net>: > I'm not aware of any other attempts, and there have never been official > plans. It's difficult to partition input for opus at anything other than > the track level, because of the way

...____ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200331/919d9b1c/attachment-0001.html>

It appears that this behaviour of InstCombine is at least somewhat intended, as there are several tests that fail after the change mentioned before: cast.ll, gep-addrspace.ll and getelementptr.ll in test/Transforms/InstCombine. I feel a little uncomfortable applying the patch after knowing this, and removing those tests doesn't seem like a great solution. What are your thoughts? For now, I

Similar to how `operator new(size)` can be overridden during linking, to capture and customize all memory allocation operations, I'd like to be able to capture all scenarios where memory is copied or moved. I've tried to use `--wrap memcpy` with some success, however I've noticed that in some instances (e.g. copying a small struct) the memcpy instruction in the IR is replaced with a

...es poner tu felicidad en la felicidad de otro" - Leibniz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: <http://lists.xiph.org/pipermail/opus/attachments/20200331/b3e64645/attachment.sig>

...ere any way to disable Dovecot LDA? I want to always send email via postfix and relay server even it will be a local delivery within the Dovecot server Thanks, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://dovecot.org/pipermail/dovecot/attachments/20200331/099b2d6f/attachment.html>

Hi Dylan, the following code volatile uint8_t v1; volatile uint8_t v2; __attribute__((interrupt)) void __vector_21(void) { v2 = v1; } produces in C mode: 00000092 <__vector_21>: 92: 80 91 61 00 lds r24, 0x0061 ; 0x800061 <v1> 96: 80 93 60 00 sts 0x0060, r24 ; 0x800060 <__data_end> 9a: 08 95 ret and in C++ mode: 00000074

> On Mar 30, 2020, at 4:13 AM, Jeremy Morse via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Sourabh, > > On Mon, Mar 30, 2020 at 8:09 AM Sourabh Singh Tomar via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Under what circumstances should a frontend choose to emit(at -O0(No optimization)) llvm.dbg.value for a local variable. >> >> I

Hi Rithik, CodeMoverUtils is not aimed for only loop transformations, it can be used by any transformation which want to move code or check if code is safe to be moved. It can currently do both hoist and sink but require control flow equivalent between the original location and the intended to be moved location. I would like to keep the API decoupled from loop, so other transformation can use it.

...CALLSTACKUP 0, 0, 14, $noreg, implicit-def dead $sp, implicit $sp > tBX_RET 14, $noreg -------------- next part -------------- A non-text attachment was scrubbed... Name: reduced.c Type: text/x-csrc Size: 329 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200331/5b9500b3/attachment-0001.c> -------------- next part -------------- A non-text attachment was scrubbed... Name: reduced.s Type: application/octet-stream Size: 1752 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200331/5b9500b3/attachment-0002.obj> --...

...s.llvm.org <mailto:llvm-dev at lists.llvm.org> > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200331/ef657e4e/attachment-0001.html>

Hi Johannes: 1. Attached is the submitted PDF. 2. I have a notes section where I state: I am still unsure of the GPU extension I proposed as I dont know how LLVM plays into the GPU cross over space like how nvcc (Nvidia's compiler integrates gcc and PTX) does.I dont know if there is a chance that function graphs in the CPU+GPU name spaces are seamless/continupus within nvcc or if nvcc is just