similar to: SD virt regs question

So if I first create the value in an entry BB and then build a CopyToReg but then I have to read it in a BB that loops back to itself, with it's own CopyToReg at the end, then I have two CopyToReg nodes for the same value. In this case, I need to create 3 virt regs, 1 for each CopyToReg and a third for the CopyFromReg in the beginning of the loop BB, right? And then I need to build a PHI

On Aug 15, 2011, at 1:27 AM, Ghassan Shobaki wrote: > One factor that is causing our current register pressure estimate to be off is not being able to properly account for live-in and live-out registers (both virtual and physical). As far as we can tell, LLVM represents live-in regs with CopyFromReg instrs and live-out regs with CopyToReg instrs. However, it looks that in a given basic block,

On 5/9/07, David Greene <greened at obbligato.org> wrote: > > Can someone explain the terminology used in the Doxygen > comments for EquivalenceClasses? Specifically, what is > a "Leader" as opposed to other members of an equivalence > class? As far as I understand, leader is the first element of the class within the std::set container where all element of all

Hi, We are working on a research project whose objective is developing a pre-allocation scheduling algorithm that achieves the optimal balance between exploiting ILP (hiding latencies) and minimizing register pressure.  A prototype of our algorithm has been implemented and integrated into an experimental version of LLVM 2.9. Our algorithm is based on a combinatorial optimization approach, which

Hi all, Our target does not have native support for 64-bit integers, so we rely on library calls for certain operations (like sdiv). We recently ran into a problem where these operations that are expanded to library calls aren't maintaining the proper ordering in relation to other chains in the DAG. The following snippet of a DAG demonstrates the problem. t0: ch = EntryToken t2:

I come across a situation that I am having a hard time to understand. When I compile the following code : char *tst( char *dest, const char *src, unsigned int len ) { for (int i=0 ; i<len ; i++) { dest[i] = src[i]; } return dest; } Clang generates this for the ‘for’ body: for.body: ; preds = %for.cond %arrayidx = getelementptr inbounds i8,

On Thu, Feb 18, 2016 at 11:48 AM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > On 2/18/2016 1:40 PM, Rail Shafigulin wrote: > >> >> 0x3283608: i32,ch = CopyFromReg 0x3257980, 0x3283500 [ORD=1] >> [ID=9] >> 0x3283500: i32 = Register %vreg5 [ID=1] >> >> Based on the code above, CopyFromReg is a node at

The current LLVM CVS HEAD does not build for me (RedHat 9). The issue is a one line fix. The file "include/llvm/ADT/EquivalenceClasses.h" needs to include <stdint.h> in order to get the typedef for "intptr_t." If anyone wants me to make a patch for this, let me know. The build error that this solves is: llvm[3]: Compiling DataStructure.cpp for Debug build In file

getOrInsertLeaderValue cannot be const because it calls insert. Index: include/llvm/ADT/EquivalenceClasses.h =================================================================== --- include/llvm/ADT/EquivalenceClasses.h (revision 108148) +++ include/llvm/ADT/EquivalenceClasses.h (working copy) @@ -169,7 +169,7 @@ /// getOrInsertLeaderValue - Return the leader for the specified value that is

Is there any way to get it to delay this optimization where it goes from this: Initial selection DAG: BB#0 'bclr64:entry' SelectionDAG has 14 nodes: t0: ch = EntryToken t2: i64,ch = CopyFromReg t0, Register:i64 %vreg0 t4: i64,ch = CopyFromReg t0, Register:i64 %vreg1 t6: i64 = sub t4, Constant:i64<1> t7: i64 = shl Constant:i64<1>, t6

Hi, On SystemZ there are a set of "access registers" that can be copied in and out of 32-bit GPRs with special instructions. These instructions can only perform the copy using low 32-bit parts of the 64-bit GPRs. As reported and discussed at https://bugs.llvm.org/show_bug.cgi?id=44254, this is currently broken due to the fact that the default register class for 32-bit integers is

Hi everyone, I have the following code (as part of a larger function): %0 = icmp eq i16 %a, 0 ; <i1> [#uses=1] br i1 %0, label %bb1, label %bb I would like to match this with a BRCOND, but all I get is an error message when compiling the above code that say: LLVM ERROR: Cannot yet select: 0x170f200: ch = br_cc 0x170f000, 0x170ed00, 0x170dc60, 0x170ec00, 0x170ef00 [ID=19]

Hello. I'm having problems at instruction selection with my back end with the following basic-block due to a vector add with immediate constant vector (obtained by vectorizing a simple C program doing vector sum map): vector.ph: ; preds = %vector.memcheck50 %.splatinsert = insertelement <8 x i64> undef, i64 %i.07.unr, i32 0

In my target I want to have mem-mem operations. But PHI instructions use virtual registers and gets converted to a series of CopyFromReg and CopyToReg instructions. These DAGs end up using physical registers. My first approach was to spill the virtual register to force a mem-mem operation. But I was unable to do this using LowerOperation() and setOperationAction(ISD::CopyToReg, MVT::i32, Custom);

Hi there, I am currently trying to create an LLVM Backend for a RISC architecture and running into problems with setCC and brcond. First a few explanations: The architecture doesn't have a dedicated flag register, but seven 1-bit-wide so called "condition registers", c0-c6, which can be set by e.g. a compare instruction: > cmp ne, c0, r1, 123 It also supports conditional

Setting the ISD::ROTL to Expand doesn't work? (via SetOperation) You could also do a Custom hook if that's what you're looking for. On Thu, Nov 3, 2016 at 5:12 PM, Phil Tomson <phil.a.tomson at gmail.com> wrote: > ... or perhaps to rephrase: > > In 3.9 it seems to be doing a smaller combine much sooner, whereas in 3.6 > it deferred that till later in the

Evan Cheng wrote: > On Jul 1, 2008, at 3:42 PM, Richard Osborne wrote: > > >> Evan Cheng wrote: >> >>> On Jun 25, 2008, at 5:13 AM, Richard Osborne wrote: >>> >>> >>> >>>> Evan Cheng wrote: >>>> >>>> >>>>> On Jun 23, 2008, at 5:35 AM, Richard Osborne wrote:

One option may be to prevent the formation of ROTL, if possible, and then generating rol by hand. Marking it as "expand" would likely stop the DAG combiner from creating it. Then you could "preprocess" the selection DAG before the instruction selection and do the pattern matching yourself. -Krzysztof On 11/3/2016 4:24 PM, Phil Tomson via llvm-dev wrote: > I could try

Hi Krzysztof, Sure, please see below. DAG.dump.() before and after, annotated with what I believe the DAG means. I've spent some time debugging the method but it's proving difficult to determine where the logic is misfiring. Disabling the entire combine causes a lot of failing x86-64 tests - I may have to learn an upstream vector ISA to make progress on this. Thank you >From your

Hi All, I have a question about splitting 'EXTRACT_VECTOR_ELT' with 'v2i1'. I have a llvm IR code snippet as following: llvm IR code snippet: for.body: ; preds = %entry, %for.cond %i.022 = phi i32 [ 0, %entry ], [ %inc, %for.cond ] %0 = icmp ne <2 x i32> %vecinit1, <i32 0, i32 -23> %1 = extractelement <2 x i1>