similar to: [LLVMdev] PrologEpilogProblems;

Hi, I'm trying to understand how virtual regs are assigned to operands in IR instructions. I looked into SelectionDAG but could not figure out where the assignment happens. How and where does this conversion happen? Furthermore, I want to build a map between variable and the virtual register (x corresponds to vreg11 in below code). I've been stuck here for a while. Any help is greatly

Hello, I've hit an assertion in SelectionDAG where we try to merge 2 loads that have the same operands but their MMO flags differ. One is dereferenceable and one is not. I'm not sure what the underlying issue here is: 1) MDSDNode with the same operands should have the same flags set on their respective MMO. The fact the flags differ when the opcode,types,operands and address-space are

Hi, while writing my register allocator, I have come across a case which confuses me because the llvm definition cannot be mapped to machine code. For instance I come across (1) and I reduce it to (2). However a copy instruction cannot move from EDX to CX. What mechanics in LLVM will tell me that I cannot make this move during register allocation, or how can I tell from (1) that I cannot execute

I am wondering about register allocation when there is a kill flag on the MachineOperand. Do I need to remove the kill flag? This code below is just an example from test\CodeGen\X86\xor.ll # Machine code for function test3: Frame Objects: fi#-2: size=4, align=4, fixed, at location [SP+8] fi#-1: size=4, align=8, fixed, at location [SP+4] Function Live Outs: %EAX BB#0: derived from LLVM BB

On Mar 6, 2012, at 5:05 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > I am having trouble trying to enable post RA scheduler for the Mips backend. > > This is the bit code of the function I am compiling: > > (gdb) p MF.Fn->dump() > > define void @PointToHPoint(%struct.HPointStruct* noalias sret > %agg.result, %struct.ObjPointStruct* byval %P) nounwind {

I am having trouble trying to enable post RA scheduler for the Mips backend. This is the bit code of the function I am compiling: (gdb) p MF.Fn->dump() define void @PointToHPoint(%struct.HPointStruct* noalias sret %agg.result, %struct.ObjPointStruct* byval %P) nounwind { entry: %res = alloca %struct.HPointStruct, align 8 %x2 = bitcast %struct.ObjPointStruct* %P to double* %0 = load

On Feb 4, 2013, at 8:59 AM, "Sergei Larin" <slarin at codeaurora.org> wrote: > Jakob, > >> The intention was to identify code that may have been converted from >> the old style a little too quickly. I wanted to avoid bugs from a >> global s/setIsInsideBundle/bundleWithPred/g search and replace. > > This is a good intent. Maybe a bit temporal but

Hi, I have a problem in our 3.0-based backend that I'm not sure how it should be handled. In summary, I don't know if * The regalloc verifier is too picky? * The register allocator is at fault for spilling the full register when only parts of it are defined? * Something else? The architecture I'm compiling for has registers with three disjoint parts: g, h and l. In one function we

Here's another data point that may be useful. [Scheduling experts, please help! :) ] If the two-byte bitfield is replaced by a two-byte struct (replace "short i:8" with "short i", etc.), the scheduler properly generates a dependency between the store and the load. For this case, a GEP is used instead of a bitcast:

On Mar 7, 2012, at 11:34 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > I filed a bug report (Bug 12205). > Please take a look when you have time. > > Per your suggestion, I also attached a patch which attaches to load or > store nodes a machinepointerinfo that points to a stack frame object > when it can infer they are actually reading from or writing to the >

Hi Sergei, Andy, Sorry - I got distracted with some other work. I'm looking into this and PR13719 now. I'll let you know what I find out. Sergei - thanks very much for the investigation. That should help me pin this down. Cheers, Lang. On Tue, Aug 28, 2012 at 2:33 PM, Sergei Larin <slarin at codeaurora.org> wrote: > Andy, Lang, > > Thanks for the suggestion. >

Arnold, It is not my code per say - this is what is done in LiveIntervalAnalysis.cpp collectRanges(), it wants to iterate over "units" of D1 (whatever they are assumed to be), but right there it associates them with actual physical register live ranges (see the tread below), and it does it wrongly. I was trying to pinpoint exactly to where the issue is, but there are too many

I filed a bug report (Bug 12205). Please take a look when you have time. Per your suggestion, I also attached a patch which attaches to load or store nodes a machinepointerinfo that points to a stack frame object when it can infer they are actually reading from or writing to the stack. The test that was failing passes if I apply this patch, but I doubt this is the right approach, because this

Hello Jakob and everyone, I am observing an issue with MCRegUnitIterator in my back end, and trying to reverse engineer some of the table gen magic around it, but if you or someone readily knows the answer, I would highly appreciate it. Here is the problem. In my back end we have a rather simple int register file structure: // Integer registers. def R0 : Ri< 0, "r0">,

Lang, I think I am getting closer to understanding this. The findLastUseBefore() should probably look something like this: // Return the last use of reg between NewIdx and OldIdx. SlotIndex findLastUseBefore(unsigned Reg, SlotIndex OldIdx) { SlotIndex LastUse = NewIdx; if (TargetRegisterInfo::isPhysicalRegister(Reg)) { for (MCRegUnitRootIterator Roots(Reg,

Hi Sergei, Thanks for the response! We just discovered there is likely a bug happening during post-RA list scheduling. There's an invalid successor index in the scheduling graph that is probably supposed to be the missing arc. Starting to investigate further now. This is recorded in http://llvm.org/bugs/show_bug.cgi?id=13891. Thanks, Bill On Fri, 2012-09-21 at 11:15 -0500, Sergei Larin

Hi Sergei, I just fixed the broken test case for PR13719 with r163107, but from the debugging output you've posted it suspect it won't fix your test case. Your analysis looks good - findLastUseBefore(..) doesn't appear to be handling physregs. I'm surprised that isn't causing more failures. I'll see if I can find a failing case in the LLVM test-suite (it's been a

Jakob, > The intention was to identify code that may have been converted from > the old style a little too quickly. I wanted to avoid bugs from a > global s/setIsInsideBundle/bundleWithPred/g search and replace. This is a good intent. Maybe a bit temporal but sound nevertheless. > finalizeBundle is calling 'MIBundleBuilder Bundle(MBB, FirstMI, > LastMI)' which ought to

Thank you for your suggestions. I implemented the first approach (provided the byval argument and offset to MachinePointerInfo) and it seems to have fixed the instruction ordering problem. It was a lot simpler than initially expected. In this particular case, is the user responsible for providing alias information to MachinePointerInfo to guarantee instructions are emitted in the correct order?

Hi Sergei, Register units != sub registers. Register units are an abstraction to describe overlapping of registers effectively. You probably wanted to use MCSubRegIterator. On Thu, Aug 30, 2012 at 2:30 PM, Sergei Larin <slarin at codeaurora.org> wrote: > Hello Jakob and everyone, > > I am observing an issue with MCRegUnitIterator in my back end, and trying > to reverse