similar to: [LLVMdev] llvm-gcc: code generated for pre- and post-increment

----- Original Message ----- > From: "Dmitry Antipov" <antipov at dev.rtsoft.ru> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Renato Golin" <renato.golin at linaro.org>, llvmdev at cs.uiuc.edu > Sent: Thursday, April 4, 2013 3:22:05 AM > Subject: Is r174746 broken on ARM? > > Hello Hal, > > I have a strong suspicion

On 04/04/2013 05:09 PM, Hal Finkel wrote: > Looking briefly at the code in comment 5 of PR15581, is that the pre-decrement case? > I can't test that case on PPC, so I can certainly believe that there is a problem somewhere. > The relevant code is a little farther down: > > APInt OV = > cast<ConstantSDNode>(Offset)->getAPIntValue(); > if (AM ==

Hello Hal, I have a strong suspicion that your constant folding optimization introduced at r174746 is broken on ARM. There is a bug about it: http://llvm.org/bugs/show_bug.cgi?id=15581 There is no such issue with 3.2, and reverting r174746 on top of r178740 also fixes the problem. I'm trying to fix it myself, but still have no good ideas; so it would be great to have an advice from you.

I have a rudimentary implementation for load and store instructions, where the memory address operand is automatically post-incremented when the load or store instruction is issued. However, this is currently coded using custom lowering, and explicit pattern matching in the 'ISelDAGtoDAG' implementation. But it seems to me that I ought to be able to achieve this exclusively using

Dear all, From what I can gather, there is currently no way for loop strength reduction to target pre- and post-increment addressing modes. This is because the target hook `isLegalAddressingMode` in TargetTransformInfo.h doesn’t allow for pre- and post-increment. There is in fact a comment to that effect on the function prototype: “TODO: handle pre/postinc as well” (see

Thanks Steve, I will try this out. I hadn’t realised that TableGen was restricted to matching instructions with more than one output operand. I’m assuming that this is only a limitation for inferring an instruction from the patterns, because it does seem to manage schedules okay. Curiously, my memory Reg32+Reg16 pattern is very similar to yours (the 16-bit offset is sign-extended though):

On 2016-09-27 02:28, Philip Reames wrote: > On 09/20/2016 12:05 PM, Matti Niemenmaa via llvm-dev wrote: >> I posted some questions related to implementing inference of nsw/nuw >> flags based on known icmp results to Bug 30428 ( >> https://llvm.org/bugs/show_bug.cgi?id=30428 ) and it was recommended >> that I engage a wider audience by coming here. The minimal context is

----- Original Message ----- > From: "Sergei Larin" <slarin at codeaurora.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: llvmdev at cs.uiuc.edu > Sent: Friday, March 1, 2013 10:24:39 AM > Subject: Interesting post increment situation in DAG combiner > > Hal, (and everyone who might care about post increment generation)... Sergei, Perhaps

Hal, Here is my patch for the post inc case. I think it is symmetrically applicable to the pre-inc, but I have not tested it for that. I think you can clearly see my intent here - I simply select the "latest" candidate when multiple are available. Who else might be interested in this? Sergei --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The

Hi, I read section 5, oop, of the R lang doc, and I am still not sure I understand how to build a class in R for oop. I thought that since I understand the oop syntex of Java and VB, I am wondering if the R programmig experts could help me out by comparing and contrasting the oop syntex in R with that of Java. For example, the basic class structure in Java is like this: public class Bicycle {

Hi there, I want to set up an extension set that acts different depending on the count of used lines. I have a EuroISDN E1 board with mISDN and I only want to offer 10 lines. Therefore I set up a global variables LINES in the general section of extensions.conf and instantiate it with 0. I a call is incoming I check the LINES variable wether is 10 or more. If so I make a call transfer. If not

Reid, After your recent redefinition of arg_iterator, it's missing increment/decrement operators (which people typically expect to be defined for iterators). So some external code relying on this is broken. If it's not intentional, would be nice to have it fixed. Specific code that I is broken looks like this: llvm::Function f; foo(--f->arg_end()); // passing the last argument to the

Hal, (and everyone who might care about post increment generation)... I have an interesting question/observation. Consider this vector loop. void vec_add_const(unsigned N, short __attribute__ ((aligned (16))) *A, short __attribute__ ((aligned (16))) val) { unsigned i,j; for (i=0; i<N; i++) { for (j=0; j<N; j++) { A[i*N+j] += val; } } } The

Hi all, I am analyzing auto inc/dec optimization on ARM. On some loops, I noticed aggressive post increment is resulting in poor code due to increased register pressure. I was wondering if there is a way to estimate register pressure during DAG Combiner. I am trying to come up with some heuristic based on # of DAG nodes, # of live ins and live outs, # of machine registers etc. Any suggestions?

Is overriding ActiveRecord#save verboten? Doing this causes increment! and decrement! to break (1 for 0 argument error): def save create_or_update # also tried ''super'' # do stuff end Joe -- Posted via http://www.ruby-forum.com/.

The method is here: https://github.com/rails/rails/blob/master/activerecord/lib/active_record/persistence.rb#L288. The method takes the in-memory attribute value and increments it by the specified amount. A safer approach (from an isolation standpoint) would be to let the database determine the value. Instead of telling the database what value to persist in the database, the SQL can written

> The predecrement / decrement operators *do* exist on this iterator: > https://github.com/llvm-mirror/llvm/blob/master/include/ > llvm/ADT/ilist_iterator.h#L153 > > Maybe you meant: > > llvm::Function *f; > foo(&*--f->arg_end()); > > ? > Correct, I mean exactly this. Though &* is not important in this case. This code doesn't work anymore, as

Hi, I'm trying to enable the pre-decrementing and post-incrementing based addressing modes for my target. So far without any success :( I enabled these modes in my TargetLowering class using setIndexedLoadAction and setIndexedStoreAction calls. I also defined getPreIndexedAddressParts and getPostIndexedAddressParts. And I can see that DAGCombiner::CombineToPostIndexedLoadStore is invoked.

Fedor Sergeev <fedor.sergeev at azul.com> writes: > On 06/12/2018 12:04 AM, David A. Greene wrote: >> // PIA - PassInstrumentationAnalysis >> if (PIA->skipTransformation()) { >> return; >> } >> // Do it. >> PIA->didTransformation(); > That should be easily doable (though the interface would be part of > PassInstrumentation > rather

On 9/15/20 9:29 AM, Christoph Hellwig wrote: > On Mon, Sep 14, 2020 at 04:53:25PM -0700, Ralph Campbell wrote: >> Since set_page_refcounted() is defined in mm_interal.h I would have to >> move the definition to someplace like page_ref.h or have the drivers >> cal init_page_count() or set_page_count() since get_page() calls >> VM_BUG_ON_PAGE() if refcount == 0. >>