similar to: [LLVMdev] Spilling of partly (un)defined registers

Hi everyone I'm hitting an assertion in PHIElimination.cpp:375. "Terminator instructions cannot use virtual registers unless" "they are the first terminator in a block!" I was looking at the code around that location a bit and have not found a reason why this assertion has to hold, except for a comment: // In our final twist, we have to decide which instruction

I have already written about something similar (either on the list, or in private communication), so this may look familiar. Here's a scenario I'm observing: First, we have some innocent looking code: vreg(32) = x // vreg(32) = 32-bit register ... = vreg(32) [...] vreg(64).low_half = vreg(32) // vreg(64) = 64-bit register [...] then, after register

Hello. Does anybody have an idea why I'm getting the error below when using llc with arguments -O1 -disable-cgp? Note that this error is not given when using llc -O0. (I'd like to mention also I'm using custom Instruction selection for BUILD_VECTOR, which gets converted in my back end's machine instrution VLOAD_D, although the custom code seems to always select

Hi Ehsan, In some cases modulo scheduling will insert copy instruction that end up as real copies in the final code. It unavoidable in some cases. For example, let's say a instruction defining a value is scheduled in the first iteration, but one of its uses is scheduled two iterations later. In this case, the kernel needs to create a copy because there will be two values live in the

Hi Quentin, On 08/19/14 18:58, Quentin Colombet wrote: [...] > It seems that you will have to debug further the *** Bad machine code: Instruction loads from dead spill slot *** before we can be of any help. Yes, I've done some more digging. Sorry for the long mail... I get: Inline spilling aN40_0_7:%vreg1954 [5000r,5056r:0)[5056r,5348r:1) 0 at 5000r 1 at 5056r At this point I have

Thanks! Our bug is now fixed. Our getMatchingSuperRegClass is huge (more than 300 lines), messy, and incomplete. > Or you could just rebase. On trunk, TableGen writes this difficult function for you. That in itself would be a compelling reason to get the rebase to trunk done. I just curious how large the generated version will be. :-) /Patrik Hägglund -----Original Message----- From: Jakob

On Jan 19, 2012, at 2:16 AM, Patrik Hägglund <patrik.h.hagglund at ericsson.com> wrote: > Is it intended that in some cases it is necessary to use > "-disable-cross-class-join" to be sure the resulting code is ok? No. > I have several cases where cross class joins are carried out that makes > the code turn out illegal, because the "new" register class is

Hi, Is it intended that in some cases it is necessary to use "-disable-cross-class-join" to be sure the resulting code is ok? I have several cases where cross class joins are carried out that makes the code turn out illegal, because the "new" register class is not allowed in all instructions where it is now used. For example, by joining %vreg4, %vreg7 and %vreg9 the

Hi - I replied to the original sender only by mistake. Sorry about that. When we started working on the pipeliner, and added it before the scheduler, we also were concerned that the scheduler or other passes would undo the work of the pipeliner. The initial thought was that we would add information (using metadata or some other way like you've suggested) to the basic block to tell the

Hi, I have some questions about the implementation of Software pipeline in MachinePipeliner.cpp. First, in hexagon backend, between MachinePipeliner and regalloc pass, there're some other passes like phi eliminate, two-address, register coalescing, which may change or insert intructions like 'copy' in MBB, and swp kernel loop may be destroyed by these passes. Why not put

On Oct 8, 2013, at 2:06 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > What I didn't mention in r192119 is that mthi/lo clobbers the other sub-register only if the contents of hi and lo are produced by mult or other arithmetic instructions (div, madd, etc.) It doesn't have this side-effect if it is produced by another mthi/lo. So I don't think making mthi/lo clobber the