similar to: 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

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

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

"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

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

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?

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

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

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

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'

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

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,

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() {

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

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

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

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

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

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)

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