search for: dmitris

*** BLURB HERE *** Bean Huo (5): fs/buffer: clean up block_commit_write fs/buffer.c: convert block_commit_write to return void ext4: No need to check return value of block_commit_write() fs/ocfs2: No need to check return value of block_commit_write() udf: No need to check return value of block_commit_write() fs/buffer.c | 24 +++++++-----------------

Remove our (soon to be) bouncing email addresses, and update Dmitri's address. Dmitry will take over as maintainer for CAIF from now on. Cc: Vikram Arv <vikram.arv at stericsson.com> Cc: Dmitry Tarnyagin <dmitry.tarnyagin at stericsson.com> Cc: Dmitry Tarnyagin <dmitry.tarnyagin at lockless.no> Signed-off-by: Sjur Br?ndeland <sjur.brandeland at stericsson.com> ---

Remove our (soon to be) bouncing email addresses, and update Dmitri's address. Dmitry will take over as maintainer for CAIF from now on. Cc: Vikram Arv <vikram.arv at stericsson.com> Cc: Dmitry Tarnyagin <dmitry.tarnyagin at stericsson.com> Cc: Dmitry Tarnyagin <dmitry.tarnyagin at lockless.no> Signed-off-by: Sjur Br?ndeland <sjur.brandeland at stericsson.com> ---

Hi, Yes, that's what I would do. If you want LLVM and the register allocator to also know that the instruction explicitly defines the register, I would designate the register into it's own register class and have your instruction write to that class (and there will be only a single option for RA). cheers, Sam Sam Parker Research Student Electronic Systems Design Group Loughborough

Hi, I'm not sure. But in your lowered DAG the chain nodes are the first operands for you custom nodes, however for the other nodes the chain is the last operand. I seem to remember that during targetlowering the chain is the first operand and then it seems to switch over after ISelDAG, this confused me and may have something to do with the issue that you are seeing. I really don't

Hi Thierry, Thanks for that, the trouble is functions are package specific so moving from one package to another could be a solution, but I would rather save that as a last resort. As mentioned, creating a package C with all the common functions could also be an option, but this strategy quickly inflates the number of packages on CRAN. If no other option is possible, that could be the way but I

Hi Dmitri, If you have such a simple intrinsic which operates on a single register, just lower the intrinsic to a target specific node which is only implemented by a single instruction. Like you were doing before and by using a chain operand. Hard code the instruction to use and define the global register and only pass the instruction the actual variable argument. Hope that helps, Sam Sam

Nadav, You are absolutely right, it's ISPC workload. I've checked SSE4 and it's also severely affected. We use intrinsics only for conversion <N x i32> <=> i32, i.e. movmsk.ps. For the rest we use general LLVM instructions. And I actually would really like to stick this way. We rely on LLVM's ability to produce efficient code from general LLVM IR. Relying on

Hello, JFYI so that no work will be duplicated. My colleagues and I will take care of converting the rest of the documentation to rst. Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/

@Dmitry, you may get more traction by reporting this issue (with patch) at https://www.openssh.com/report.html . It can also help other folks who may be encountering the same issue. -- jmk > On Mar 3, 2023, at 02:10, Dmitry Belyavskiy <dbelyavs at redhat.com> wrote: > > ?Dear colleagues, > > Could you please take a look? > >> On Fri, Jan 20, 2023 at 12:55?PM

Thanks all, I don't know either (for the moment). It's all in the design phase still. Generally, I would also like to keep specific functions in specific packages, if at all possible. On Fri, Apr 8, 2016 at 3:03 PM, Mark van der Loo <mark.vanderloo at gmail.com> wrote: > Well, I'm not saying that Dmitri _should_ do it. I merely mention it as an > option that I think is

Hi Mark, Uhm... sometimes this is not always possible. For example I have a package QCA which produces truth tables (all combinations of presence / absence of causal conditions), and it uses the venn package to draw a Venn diagram. It is debatable if one should assimilate the "venn" package into the QCA package (other people might want Venn diagrams but not necessarily the other QCA

Hi, Field RdMacros was introduced in file DESCRIPTION to allow users to import LaTeX-like macros from other packages. Currently 'R CMD Check --as-cran' gives a NOTE: > Unknown, possibly mis-spelled, field in DESCRIPTION: > ?RdMacros? A small package demonstrating this is available at http://www.maths.manchester.ac.uk/~gb/testRdMacro_0.0.2.tar.gz (and this is the source:

Hi Dmitry, ISPC does some instruction selection as part of vectorization (on ASTs!) by placing intrinsics for specific operations. The SEXT to i32 pattern was implemented because LLVM did not support vector-selects when this code was written. Can you submit a small SSE4 test case that demonstrates the problem? Select is the canonical form of this operations, and SEXT is usually more

On Thu, Jan 17, 2013 at 1:19 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote: > On Wed, Jan 16, 2013 at 9:33 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote: >> On Wed, Jan 16, 2013 at 9:24 PM, Chris Lattner <clattner at apple.com> wrote: >>> >>> On Jan 16, 2013, at 10:32 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote: >>>

Note that as far as places to put temporary files, the right place to put them is alongside the other test outputs in the test output "sandbox" directory. Somewhat orthogonal, but we should also fix up lit to purge those sandboxes before it starts a new test run. - Daniel On Wed, Jan 16, 2013 at 3:31 PM, Dmitri Gribenko <gribozavr at gmail.com>wrote: > On Thu, Jan 17, 2013

A third possibility, which I use in my gtools and gdata packages, is to use soft-links to create a copy of the relevant functions from one package in the other. I make sure these functions are *not* exported, so no conflicts are created, and the use of soft-links mean the code never gets out of sync. -Greg -- Change your thoughts and you change the world. --Dr. Norman Vincent Peale > On

Seems to be broken in the current SVN: [...] x86_64-linux-gnu-gcc -I../include -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -DINET6 -O2 -D_REENTRANT -DNETSNMP_USE_INLINE -Wall -Dlinux -I. -I/usr/include -O2 -Wall -Wsign-compare -s -o energizerups energizerups.o ../common/upsconf.o ../common/parseconf.o ../common/state.o main.o dstate.o

On Thu, Jan 17, 2013 at 1:23 AM, Evgeniy Stepanov <eugeni.stepanov at gmail.com> wrote: > On Thu, Jan 17, 2013 at 1:19 AM, Dmitri Gribenko <gribozavr at gmail.com> wrote: >> On Wed, Jan 16, 2013 at 9:33 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote: >>> On Wed, Jan 16, 2013 at 9:24 PM, Chris Lattner <clattner at apple.com> wrote: >>>>

Hi all, I'm primarily a hardware person but would like to do some compiler-architecture co-design research. Are there any good references for the NVPTX backend? I'd like to change that backend to have a limited number of physical registers rather than an unlimited number of virtual ones (for more realistic modeling in a uarch simulator). Being able to do register allocation and other