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

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'

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

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

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

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

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

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,

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

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

What I am thinking of now is to just register the MIPS116 and MIPS32 DAGToDAGISel passes and then within run on machine function, I can just return if the current mode indicates that mips16 is needed for example, so the run on machine function for Mips32 would return immediately. On 03/27/2013 10:05 AM, Reed Kotler wrote: > I guess another way to do this is to just register both passes for

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 the input rd SDNode be properly transferred to the output RD node instead of the MOVE node. I doubt

I'm implementing this ability to switch between mips16 and mips32 on a per function basis. One issue that I've run into is regarding the DAGToDAGIsel pass. We have a different subclass for mips16 and non mips16 ( conceivably later there could be a separate one for micromips). I need to run a different pass depending on whether it's mips16 or mips32. My initial plan was to create

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