similar to: SelectionDAGISel::Select's API considered harmful

Displaying 20 results from an estimated 2000 matches similar to: "SelectionDAGISel::Select's API considered harmful"

2016 May 21
0
SelectionDAGISel::Select's API considered harmful
Update: All in tree backends now implement `void Select`. I'll be removing the SelectImpl path on Monday. Justin Bogner <mail at justinbogner.com> writes: > TLDR: Heads up for out of tree backends - you're going to need to update > your *DAGToDAGISel::Select method to unconditionally replace nodes > directly instead of returning the desired replacement. > > So I'm
2016 May 23
2
SelectionDAGISel::Select's API considered harmful
Can you put something in the release notes when this happens? Thanks, Hans On Sat, May 21, 2016 at 10:57 AM, Justin Bogner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Update: All in tree backends now implement `void Select`. I'll be > removing the SelectImpl path on Monday. > > Justin Bogner <mail at justinbogner.com> writes: >> TLDR: Heads up for out of
2016 May 23
0
SelectionDAGISel::Select's API considered harmful
Hans Wennborg <hans at chromium.org> writes: > Can you put something in the release notes when this happens? I already updated the release notes in r268693, when I added the void Select option in the first place :) > Thanks, > Hans > > On Sat, May 21, 2016 at 10:57 AM, Justin Bogner via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Update: All in tree
2016 Jun 28
0
Question about changes to 'SelectionDAGISel.h'
"Martin J. O'Riordan" <martin.oriordan at movidius.com> writes: > Thanks Ahmed and also Alex for your replies. > > This is more or less what I was realising, but it is a great > confidence booster to know that it is the correct way also. I can > replace all of my various 'Select*' specialisations with version that > use
2016 Oct 24
2
Accessing the associated LLVM IR Instruction for an SDNode used in instruction selection (back end)
Hello. Quentin, retrieving the LLVM IR instruction from which an SDNode originates is useful during the instruction selection phase. For example, I need to recover the LLVM IR variable which is used to fill an entire vector with the ISD::BUILD_VECTOR target-independent SDNode . From the recovered LLVM IR variable I can walk on the use-def-chains in order to get the most complete
2016 Jun 28
2
Question about changes to 'SelectionDAGISel.h'
Thanks Ahmed and also Alex for your replies. This is more or less what I was realising, but it is a great confidence booster to know that it is the correct way also. I can replace all of my various 'Select*' specialisations with version that use 'ReplaceNode/SelectCode' and return 'void', but what about the places where I currently call 'Select(N)' directly?
2016 Oct 21
2
Accessing the associated LLVM IR Instruction for an SDNode used in instruction selection (back end)
Hello. I would like to access the LLVM IR Instruction from which an SDNode (from SelectionDAG) originates. For this I have modified: - llvm/lib/CodeGen/SelectionDAGISel.cpp, SelectionDAGISel::SelectBasicBlock(), namely I put SDB->clear() at the beginning of the method in order to avoid clearing NodeMap after creating the initial SelectionDAG from LLVM IR, since I want to access
2019 Jul 12
2
[cfe-dev] ARM float16 intrinsic test
Hi, I do not get your result. Do I miss something? $COMP_ROOT/clang++ --target=arm-arm-eabihf -march=armv8.2a+fp16 arm.cpp -S -o - -O3 .text .syntax unified .eabi_attribute 67, "2.09" .eabi_attribute 6, 14 .eabi_attribute 7, 65 .eabi_attribute 8, 1 .eabi_attribute 9, 2 .fpu crypto-neon-fp-armv8 .eabi_attribute 12, 4
2016 Jun 28
0
Question about changes to 'SelectionDAGISel.h'
On Tue, Jun 28, 2016 at 8:53 AM, Martin J. O'Riordan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > It occurred to me that instead of the various breakout ‘Select*’ functions > returning the ‘SDNode*’ result, maybe I should be calling: > > > > ReplaceNode(N, newValue); > > return; > > or: > > SelectCode(N); > > return; > > >
2016 Jun 28
3
Question about changes to 'SelectionDAGISel.h'
It occurred to me that instead of the various breakout 'Select*' functions returning the 'SDNode*' result, maybe I should be calling: ReplaceNode(N, newValue); return; or: SelectCode(N); return; Perhaps? MartinO From: Martin J. O'Riordan [mailto:martin.oriordan at movidius.com] Sent: 28 June 2016 16:49 To: 'LLVM Developers'
2019 Jul 12
2
[cfe-dev] ARM float16 intrinsic test
Dear list, git checkout llvmorg-8.0.0 -b llvm8.0 cmake -G "Unix Makefiles" ../llvm-project/llvm -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_PROJECTS="clang;lld" -DLLVM_TARGETS_TO_BUILD="X86;NVPTX;AMDGPU;ARM;AArch64" [arm.cpp] #define vst4_lane_f16(__p0, __p1, __p2) __extension__ ({ \ float16x4x4_t __s1 = __p1; \ __builtin_neon_vst4_lane_v(__p0, __s1.val[0],
2017 Jun 06
2
Putting "tied-to" constraints on virtual registers in SelectionDAGISel's Select() method
Hello. I expand an instruction to a sequence of MachineSDNodes at instruction selection, in the Select() method of the SelectionDAGISel class. For efficiency, in order to generate fewer instructions, I would like to assign twice to the same physical register - but since I don't want to "mess" with the register allocator, I am using only virtual registers. However,
2012 Aug 21
0
[LLVMdev] SelectionDAGISel::CodeGenAndEmitDAG() confusion.
Hello everybody, Following on from the excellent help I received at http://comments.gmane.org/gmane.comp.compilers.llvm.devel/52591 - I have a follow up question. I've been editing the SelectionDAGiSel.cpp to try and print out the operations in the nodes, to this end I have modified the SelectionDAGISel::CodeGenAndEmitDAG() function as follows void SelectionDAGISel::CodeGenAndEmitDAG() {
2017 Dec 24
4
Canonical way to handle zero registers?
Thanks, that sounds like it would work. Was this based on what any other target did? Or do any other targets take this approach? I just want to make sure that we don't already have a hook suitable for this. Overriding runOnFunction to run what could be described as just a "late SelectionDAG pass" sounds pretty intrusive. Do you remember other approaches that didn't work? --
2015 Mar 09
2
[LLVMdev] LLVM Backend DAGToDAGISel INTRINSIC
I am currently working on DAGToDAGISel class for MIPS and am trying to figure out a way to use INTRINSIC_W_CHAIN for an intrinsic which can return a value. My intrinsic is defined as: Intrinsic<[llvm_i32_ty],[llvm_i32_ty,llvm_i32_ty,llvm_i32_ty,llvm_i32_ty],[IntrReadWriteArgMem]>; i.e. it has four arguments and one return value In DAGToDAGISel when I try to pass it with four arguments and
2017 Feb 14
2
Adding FP environment register modeling for constrained FP nodes
Hi Hal, Thanks for the guidance. I hope you don’t mind that I’m adding LLVMDev to this e-mail thread, as it seems as though it may be of general interest. I agree that duplicating the FP opcodes should be our goal. I just wasn’t sure that was entirely possible. I’ll try adding implicit defs in the way you’ve suggested, but I’m concerned that there may be code that relies on the TII for that
2016 Jun 28
0
Question about changes to 'SelectionDAGISel.h'
Although I would like to track the LLVM head revisions regularly, unfortunately I only get the opportunity every couple of months or even every 6 month with a full release. This time I am updating from revision #262824 (8th March) so more than 3 months have elapsed. For the most part I have completed the changes I need to make, but I'm stuck on one change that is more significant than it
2011 Jun 24
2
[LLVMdev] Infinite loop in llc on ARMv7 (LLVM HEAD from June 17)
Hello, it looks like I do have infinite loop in llc on linux/armv7 platform somewhere in llvm::SmallVectorImpl. Two backtraces obtained with 10 seconds delay are: 0x0099be14 in llvm::SmallVectorTemplateCommon<llvm::SDNode*>::setEnd (this=0x7ee90b38, P=0x5c06988) at /export/home/karel/vcs/llvm-head/include/llvm/ADT/SmallVector.h:103 103 void setEnd(T *P) { this->EndX = P; }
2006 May 23
3
[LLVMdev] HEAD broken?
I'm getting this: /home/ghost/Work/llvm-cvs/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp: In member function `void llvm::SelectionDAGLowering::visitSetCC(llvm::User&, llvm::ISD::CondCode, llvm::ISD::CondCode, llvm::ISD::CondCode)': /home/ghost/Work/llvm-cvs/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:1107: error: ` UnsafeFPMath' undeclared (first use this function)
2008 Nov 06
0
[LLVMdev] Multi-instruction patterns, tablegen and chains
On Nov 4, 2008, at 12:12 AM, Matthijs Kooijman wrote: > Hi Dan, > >> Having tblgen pretend that the MOVE isn't the root seems a bit >> counter-intuitive though. > I didn't really mean making RD the root, but rather telling tablegen > that RD > is the "primary" node, corresponding to the input pattern. This > would allow > the properties of