search for: selectcodecommon

...nt<127> In function: my_func On Sat, Nov 4, 2017 at 7:22 PM Craig Topper <craig.topper at gmail.com> wrote: > CopyToReg is not handle by patterns. It should be passed through isel > unchanged. It’s part of a special list of ISD opcodes that don’t change in > SelectioDAGISel::SelectCodeCommon > > It will then be turned into a TargetOpcode::COPY in > InstrEmitter::EmitSpecialNode when the DAG is turned into MachineInstrs. > > On Sat, Nov 4, 2017 at 7:02 PM Robert Baruch via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> So there's a DAG that loo...

So there's a DAG that looks like this in the debug output: Selecting: t3: ch,glue = CopyToReg t0, Register:i16 %R5, Constant:i16<127> In the instruction selection phase, what pattern would that match? I've constructed this so far: (??? REG16:$dst, i16imm:$src) but the problem is, I can't determine what to use as ???. There is an ISD::CopyToReg enum value, but I don't

...at, Nov 4, 2017 at 7:22 PM Craig Topper <craig.topper at gmail.com> >> wrote: >> >>> CopyToReg is not handle by patterns. It should be passed through isel >>> unchanged. It’s part of a special list of ISD opcodes that don’t change in >>> SelectioDAGISel::SelectCodeCommon >>> >>> It will then be turned into a TargetOpcode::COPY in >>> InstrEmitter::EmitSpecialNode when the DAG is turned into MachineInstrs. >>> >>> On Sat, Nov 4, 2017 at 7:02 PM Robert Baruch via llvm-dev < >>> llvm-dev at lists.llvm.org> wr...

...@func() { %rv1 = call <4 x float>* @getPtr() %rv2 = call <4 x float>* @getPtr() %rv3 = load <4 x float>* %rv1 ret <4 x float> %rv3 } The load ends up loading from the pointer returned by the 2nd function call. I traced down the problem to calling the SelectionDAGISel::SelectCodeCommon on the load instruction. Before calling that the DAG looks OK. The selected target load ends up pointing to the "physical function call return register node" instead of the CopyFromReg node that copies the result of the 1st call to a temporary register. The physical return register is the...

On Aug 14, 2012, at 2:05 PM, Steve Montgomery <stephen.montgomery3 at btinternet.com> wrote: > Further to my earlier question, I'm perhaps a bit confused about memory serialisation. The following example, compiled using clang for the MSP430: > > target datalayout = "e-p:16:16:16-i8:8:8-i16:16:16-i32:16:32-n8:16" > target triple = "msp430-??-??" >

> No, a chain is supposed to mean "later than". It sounds like MSP430 is bending > the rules here. The instruction selector for ADD16mm is autogenerated, so, this is not MSP430 bug alone :) This is just the single target in the tree which has mem-mem instructions. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

...glue that prevents the pattern from matching (perhaps in ARMISelLowering - which *does* have custom code..) Assuming that the case is the first or second, what is the best way to associate the table information in ARMGenDAGISel.inc to the entries in the .td file? That is, while stepping through SelectCodeCommon(), I am having a difficult time associating the MatchIndex and the associated MatchTable to the entries in the .td.... Any pointers or help would be greatly appreciated. Thank you! -jason -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipe...

I'm trying to write a tablegen pattern to that matches a sequence of SDNodes and emits again an SDNode and another instruction. The pattern I've written looks like the folowing: def : Pat<(foo (bar GPR:$rs1), simm12:$imm1), (bar (BAZ GPR:$rs1, simm12:$imm1))>; foo and bar are SDNodes, BAZ is an instruction. In particular, bar is defined as follows: def bar :

...r basic blocks of size one. This can cover about 10% of the basic blocks. The code-quality drop on a few benchmarks is neglible, but for spec's 483.xalancbmk it is quite dramatic. Also, any pointers to documentation, or description of the algorithm used by the Select() -> SelectCode() -> SelectCodeCommon() pass would be very helpful. Sorry for the long email, and many thanks in advance! - Jan Voung -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100514/16e1c9ea/attachment.html>

...dst) (ins Intregs:$op0,MEMi:$op1), "", [set IntRegs:$dest (adde IntRegs:$op0, (load ADDRi:$op1))] > very unlucky, this instruction failed. in the generated match table, there was flag OPFL_Chain. it caused a token factor node to be created in switch case OPC_EmitMergeInputChains in SelectCodeCommon. very bad, all uses of input chain was replaced with ADDErm Node. so the created token factor node depends on the ADDErm node after the replacement. very bad the ADDCrm node depends on above token factor. because of the glue, a cycle formed. ADDE-->ADDC-->TF-->ADDE. after I remov...

...%rv2 = call <4 x float>* @getPtr() > %rv3 = load <4 x float>* %rv1 > ret <4 x float> %rv3 > } > > The load ends up loading from the pointer returned by the 2nd function > call. > I traced down the problem to calling the > SelectionDAGISel::SelectCodeCommon on the load instruction. Before > calling that the DAG looks OK. The selected target load ends up pointing > to the "physical function call return register node" instead of the > CopyFromReg node that copies the result of the 1st call to a temporary > register. The physical re...

.../SelectionDAG.cpp:6092:0 #10 0x00007f08fb04a3e9 llvm::SelectionDAGISel::MorphNode(llvm::SDNode*, unsigned int, llvm::SDVTList, llvm::ArrayRef<llvm::SDValue>, unsigned int) /llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:2474:0 #11 0x00007f08fb05106b llvm::SelectionDAGISel::SelectCodeCommon(llvm::SDNode*, unsigned char const*, unsigned int) /llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:3441:0 #12 0x00007f0901714eb0 (anonymous namespace)::ConnexDAGToDAGISel::SelectCode(llvm::SDNode*) /llvm/lib/Target/Connex/ConnexGenDAGISel.inc:1075:0 ... I really need the...

...+ 5.45% caching_compile caching_compiler_test [.] common::RecordParser::Stream::FileStreamAdapter::good() + 3.31% caching_compile caching_compiler_test [.] common::RecordParser::Stream::FileStreamAdapter::get() + 1.17% caching_compile caching_compiler_test [.] llvm::SelectionDAGISel::SelectCodeCommon(llvm::SDNode*, unsigned char const*, unsigned int) + 1.10% caching_compile caching_compiler_test [.] operator new(unsigned long) + 1.07% caching_compile caching_compiler_test [.] llvm::SmallPtrSetImpl::insert_imp(void const*) + 1.00% caching_compile caching_compiler_test [.] llvm::PM...

> Mehdi Amini <mehdi.amini at apple.com> 於 2016年11月30日 上午5:14 寫道： > >> >> On Nov 29, 2016, at 4:02 AM, Bekket McClane via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi, >> Though there exists lots of researches on parallelizing or scheduling optimization passes, If you open up the time matrices of

Hello. I wanted to inform that I fixed the bug from the previous email. The main reason for the bug was that I thought that the SDNode masked_gather is returning only 1 value, but it returns 2 (hence, I guess, the earlier reported, difficult to follow, error: "Assertion `New->getNumTypes() == 1"). masked_gather returns 2 values because: // SDTypeProfile -