search for: constantsdnodes

The attached patch contains: - Cleanups in the DAGCombiner.cpp ROTL/ROTR combine code, primarily helping me to fix 80col violations (benefiting the code as a whole). - Detect sign/zext/any-extended versions of ROTL/ROTR patterns. - Allow custom lowering for ROTL/ROTR (needed in the CellSPU's case for 8-bit rotates, when only 16-bit and 32-bit rotates are actually implemented in the

On Mon, Oct 10, 2016 at 8:31 PM, Chris Lattner <clattner at apple.com> wrote: > > On Oct 10, 2016, at 8:12 PM, Peter Collingbourne via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hi all, > > I wanted to summarise some discussion on llvm-commits [0,1] as an RFC, as > I felt it demanded wider circulation. > > Our support for references to absolute

On Tue, Oct 11, 2016 at 2:48 PM, Chris Lattner <clattner at apple.com> wrote: > On Oct 11, 2016, at 12:04 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > > I have been experimenting with a number of approaches to representation in >> SDAG, and I have found one that seems to work best, and would be the least >> intrusive (unfortunately most approaches to this

...on the same line. /Björn From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of via llvm-dev Sent: den 21 juni 2018 15:08 To: mbraun at apple.com Cc: llvm-dev at lists.llvm.org; davidxl at google.com; jbogner at apple.com Subject: Re: [llvm-dev] [RFC] Removing debug locations from ConstantSDNodes mbraun at apple.com<mailto:mbraun at apple.com> wrote: FWIW: Debug information on constants feels odd to me. They are just values not something that is executed so conceptually I would not expect them to "happen" at a specific time/place in the program. That said most numbers are...

Hi all, I wanted to summarise some discussion on llvm-commits [0,1] as an RFC, as I felt it demanded wider circulation. Our support for references to absolute symbols is not very good. The symbol will be resolved accurately in non-PIC code, but suboptimally: the symbol reference cannot currently appear as the immediate operand of an instruction, and the code generator cannot make any assumptions

Is it possible to get a register number to which the value is allocated to in MIPS in DAGToDAG class? More Specifically: SDValue Reg3 = Node->getOperand(3); if (RegisterSDNode *R = dyn_cast<RegisterSDNode>(Reg3)) { op3 = cast<RegisterSDNode>(Reg3)->getReg();

----- 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

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.

...avior given Swift code that looks like this: 1| var input = [16, 14, 10, 9, 8, 7, 4, 3, 2, 1] //< Only number 1 is relevant. 2| print("start") TL;DR: The debugger steps from line 2 -> 1 -> 2 in this code example. One clean way to fix this bug is to remove debug locations from ConstantSDNodes, and I'm asking if there are any objections to doing that. In more detail: The problem appears to be that we assign a debug location to the ConstantSDNode for "1". When this constant is used again (as it happens to be in the lowered version of the call to print()) the debugger steps...

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 ==

> On Feb 27, 2015, at 1:59 AM, Ambuj Agrawal <ambujbwt at gmail.com> wrote: > > Is it possible to get a register number to which the value is allocated to in MIPS in DAGToDAG class? > > More Specifically: > SDValue Reg3 = Node->getOperand(3); > if (RegisterSDNode *R = dyn_cast<RegisterSDNode>(Reg3)) >

...really wanted the line table entry for line 2 to include the constant materialization code for some VS debugger feature. Got it. (For others following along, there's more discussion about this debugger feature in the commit description for r327581.) > I think if you remove locations from ConstantSDNodes, you might want to add a late pass that propagates source locations backwards onto location-less instructions. This would also avoid some special cases when a basic block starts with an instruction that lacks location information. See CodeViewDebug::beginInstruction and DwarfDebug::beginInstruction...

I am running the following llvm-ld command to produce native code: llvm-ld -native -o code.exe code.bc -lm However, I am getting the following assertion failure in llc. The bytecode has been processed with opt, it passes opt bytecode verification. I'm not too familiar with backend code generation. Does anyone have any insight in to what the problem might be or how to go about

Thanks for your reply Quentin. I do understand that the registers are allocated much later in the pipeline. I am assuming that the physical registers are allocated before MipsAsmPrinter class. I am doing something like if (MI->getOpcode() == Mips::OPCODE) { unsigned n = MI->getNumOperands(); for(unsigned i=0 ; i < n ; i++) { const MachineOperand &MO =

The reason the ones in PPCInstrInfo.td don't have the patterns to match is the reason they are more analogous to your problem. Namely, tblgen does not have a way to produce nodes with more than one result. The load-with-update instructions do exactly that - one of the inputs is also an output, but the other output is independent (and necessarily a separate register). The FMA variants have

Hi Ryan, On Fri, 2007-04-06 at 13:34 -0500, Ryan M. Lefever wrote: > I am running the following llvm-ld command to produce native code: > > llvm-ld -native -o code.exe code.bc -lm > > However, I am getting the following assertion failure in llc. The > bytecode has been processed with opt, it passes opt bytecode > verification. I'm not too familiar with backend

...not a complete lie. > --paulr >   <> > From: vsk at apple.com [mailto:vsk at apple.com] > Sent: Wednesday, June 20, 2018 1:48 PM > To: Reid Kleckner > Cc: Robinson, Paul; llvm-dev; Justin Bogner; David Li; David Blaikie > Subject: Re: [RFC] Removing debug locations from ConstantSDNodes > > On Jun 19, 2018, at 6:36 PM, Reid Kleckner <rnk at google.com <mailto:rnk at google.com>> wrote: > > On Tue, Jun 19, 2018 at 5:46 PM Vedant Kumar <vsk at apple.com <mailto:vsk at apple.com>> wrote: > Someone (Reid?) mentioned that we could try sinking...

Is a PR a bug report on the bugzilla database? I am also running bugpoint to see if that yields anything. Reid Spencer wrote: > Hi Ryan, > > On Fri, 2007-04-06 at 13:34 -0500, Ryan M. Lefever wrote: > >>I am running the following llvm-ld command to produce native code: >> >>llvm-ld -native -o code.exe code.bc -lm >> >>However, I am getting the

Hi, I am trying to write a LowerCALL() function for my (custom) target ISA. All I need to do is map a CALL instruction directly onto an SDNode that takes an equal number of arguments (very much alike intrinsics, except that these are custom to my target.) I do not need to implement any call sequences, stack frames etc. I get the following assertion failure: llc: LegalizeDAG.cpp:834:

I'm not sure how many people are using Visual Studio to build the llvm tools, other than myself? When I compile the llvm tools on linux I do not see any warnings (I believe -Wall is set?). However, under visual studio there are a lot of warnings, mostly of this form: warning C4244: 'initializing' : conversion from 'uint64_t' to 'unsigned int', possible loss of data