search for: iseldag

...r an architecture I am designing in my bachelor's thesis and recently came across the GlobalISel Selection Framework. Should already start using this over the more common Selection DAG? Being new llvm backend development, I am not sure if GlobalISel would be "easier" to implement than ISelDAG and if there is any decent documentation on how to do so. Cheers, Floris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200213/3dbbfb84/attachment.html>

...and a reasonable > stepping-stone to generic load-linked instructions or intrinsics. The problem is that the optimisations that we're most interested in should be done by the mid-level optimisers and are architecture agnostic. > In my experience, CodeGen has improved with the change. ISelDAG gets > to make use of more information when choosing how to do the operation: > values already known to be sign/zero extended, immediates, etc. Yes, it's definitely an improvement in the short term, but I'm not convinced by the approach in the long term. It's a useful hack that...

...InlineAsmOperands it seems to be something like: 'Code | (Size << 3)' with Code on of these values: 1 REGUSE 2 REGDEF 3 IMM 4 MEM/ADDR are there any other values? and would it be safe to change 4 to MEMUSE and add 5 (MEMDEF)? i do not know where these values are used (except for the ISelDAG and the AsmPrinter). florian

> On Jul 3, 2019, at 4:43 PM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > -----Original Message----- > From: David Greene <dag at cray.com> > Sent: Wednesday, July 3, 2019 2:44 PM > To: Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> > Cc: Krzysztof Parzyszek <kparzysz at quicinc.com> > Subject: [EXT] Re:

On 10 May 2014, at 16:18, Tim Northover <t.p.northover at gmail.com> wrote: > Actually, I really agree there. I considered it recently, but decided > to leave it as an intrinsic for now (the new IR expansion pass happens > after most optimisations so there wouldn't be much benefit, but if we > did it earlier and the mid-end understood what an ldrex/strex meant, I > could

...sed for memory access, which is the common part between yours and ours. Here are 2 possible solutions for our problem: 1. constrain instruction selection. 1.1 use "addRegisterClass(MVT::iPTR, XXX::PTRRegClass);" to bind pointers and their register class. 1.2 add a pass to transform ISelDAG before instruction selection. Since we can determine from opcodes whether an operation can only take address registers as its input operands, we replace i32 with iPTR if so, and insert reg-reg move operations if necessary. For example, (load reg, addr:i32) means we read at 'addr' to fill &...

Hi, I'm not sure. But in your lowered DAG the chain nodes are the first operands for you custom nodes, however for the other nodes the chain is the last operand. I seem to remember that during targetlowering the chain is the first operand and then it seems to switch over after ISelDAG, this confused me and may have something to do with the issue that you are seeing. I really don't know much about scheduling, do you want to post your instruction definitions again to see if someone else has some ideas,. cheers, sam Sam Parker Research Student Electronic System Design Grou...

Hi, > 1 What side effects do operatios of loads/stores/calls/returns have? > (maybe i don't understand concept of side effect ) suppose you do a store to a memory location, and then load from the memory location. This is not the same as first doing the load and then only afterwards doing the store! How to represent the order in the SDAG? The SDAG is not a linear sequence of

Hi everyone, It says in document 'The LLVM Target-Independent Code Generator ': "SelectionDAGs contain two different kinds of values: those that represent data flow and those that represent control flow dependencies. Data values are simple edges with an integer or floating point value type. Control edges are represented as "chain" edges which are of type MVT::Other. These

Hi, Yes, that's what I would do. If you want LLVM and the register allocator to also know that the instruction explicitly defines the register, I would designate the register into it's own register class and have your instruction write to that class (and there will be only a single option for RA). cheers, Sam Sam Parker Research Student Electronic Systems Design Group Loughborough

Hi, In our version of LLVM, we've added different-sized iPTR* types, so we have an iPTR256 for our fat pointers. This causes some problems with constraints, because the way that TableGen resolves constraints is not expected to handle multiple pointer types. We've added a flag that can be set on a per-backend basis to turn this off. Our problem is perhaps a bit different form yours,

Could we expose predicates defined in the target InstrInfo.td file to the MachineVerifier? We use BuildMI() to create many instructions after ISEL, but the predicates are not being checked at this point. Thus, I could forget to check the target and build an instruction that is illegal for a specific configuration. In such a case it would be nice if the MachineVerifier could detect this for me.

David, thanks for your immediate response. Since iPTR is a reserved type for tablegen internal use, can you make a further explanation? On the other hand, it can be simply treated as a register class assignment problem during register allocation. Assume both pointer and integet have a 32 bit width. backend handles it just as to i32. When it performs register allocation, it can retrieve from

> On 2 May 2017, at 8:48 am, Tom Stellard <tstellar at redhat.com> wrote: > You would probably need to write a new tablegen backend to generate > instruction tables that would be used outside of LLVM. I think I need to write one anyway because I need to generate lots of tables other than the instruction table (there are no registers and therefore no register table), at least one

.../lib/Target/Mips/CMakeLists.txt b/lib/Target/Mips/CMakeLists.txt index cf8bb18..1029e3c 100644 --- a/lib/Target/Mips/CMakeLists.txt +++ b/lib/Target/Mips/CMakeLists.txt @@ -32,6 +32,8 @@ add_llvm_target(MipsCodeGen MipsLongBranch.cpp MipsMCInstLower.cpp MipsMachineFunction.cpp + MipsModuleISelDAGToDAG.cpp + MipsModuleISelLowering.cpp MipsRegisterInfo.cpp MipsSEFrameLowering.cpp MipsSEInstrInfo.cpp diff --git a/lib/Target/Mips/Mips16ISelDAGToDAG.cpp b/lib/Target/Mips/Mips16ISelDAGToDAG.cpp index 00b3449..2ffd3a9 100644 --- a/lib/Target/Mips/Mips16ISelDAGToDAG.cpp +++ b/lib/Target/M...

On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com> wrote: > IMHO the right way to handle target function attributes is to > re-initialize the target machine and TTI for every function (if the > attributes changed). Do you have another solution in mind ? I don't really understand this. TargetMachine and TTI may be quite expensive to initialize. Doing so for