similar to: [LLVMdev] Question about post RA scheduler

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

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 {

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 >

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?

Greetings, I'm investigating a bug in the PowerPC back end in which a load from a storage address is being reordered prior to a store to the same storage address. I'm quite new to LLVM, so I would appreciate some help understanding what I'm seeing from the dumps. I assume that some information is missing that would represent the memory dependency, but I don't know what form that

Hi Bill, Which scheduler do you use? MI or SDNode one? In either case the problem is likely the same, but cause might be in a different place... The way I see it, you have an issue with the alias analyzer, not scheduler. When scheduling DAG is constructed, AA is checked for pairs of mem accessing objects, and if no potential interference is flagged by the AA the chain edge is _not_ inserted.

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 Fri, 2012-09-21 at 11:34 -0500, William J. Schmidt wrote: > 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 >

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

Thanks for spelling it out, now I understand. On Jun 5, 2011, at 6:11 AM, Galanov, Sergey wrote: > Well, the point is CMOV_GR* are marked clobbering EFLAGS conservatively just in case they turn out to be lowered into a sequence containing XOR %reg,%reg which indeed clobbers EFLAGS. This means there might not be any instruction which actually uses this EFLAGS value. This actually looks like a

OK, finally found it. The AliasChain in ScheduleDAGInstrs::buildSchedGraph is not acting as a chain for loads and stores (the head of the chain is not being updated as they are encountered, so dependencies aren't being added solely on the basis of may-aliasing in some cases). Will test a patch. On Fri, 2012-09-21 at 13:04 -0500, William J. Schmidt wrote: > On Fri, 2012-09-21 at 11:34

On Jun 3, 2011, at 2:59 AM, Galanov, Sergey wrote: > Hi, Bill and Jakob. > > I don't quite understand. I am talking about CMOV_GR* instructions which are conservatively marked as clobbering EFLAGS in X86InstrCompiler.td. Doesn't that mean there cannot be any use of EFLAGS in subsequent instructions before it is defined by some other instruction? > > I also don't

Well, the point is CMOV_GR* are marked clobbering EFLAGS conservatively just in case they turn out to be lowered into a sequence containing XOR %reg,%reg which indeed clobbers EFLAGS. This means there might not be any instruction which actually uses this EFLAGS value. For an example we can look no further than the actual test which has been disabled after the fix

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

Andy, Lang, Thanks for the suggestion. I have spent more time with it today, and I do see some strange things in liveness update. I am not at the actual cause yet, but here is what I got so far: I have the following live ranges when I start scheduling a region: R2 = [0B,48r:0)[352r,416r:5)... R3 = [0B,48r:0)[368r,416r:5)... R4 = [0B,32r:0)[384r,416r:4)... R5 = [0B,32r:0)[400r,416r:4)...

On Aug 30, 2012, at 1:20 PM, Arnold Schwaighofer <arnolds at codeaurora.org> wrote: > The code in collectRanges() does: > > // Collect ranges for register units. These live ranges are computed on > // demand, so just skip any that haven't been computed yet. > if (TargetRegisterInfo::isPhysicalRegister(Reg)) { > for (MCRegUnitIterator Units(Reg,

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

The code in collectRanges() does: // Collect ranges for register units. These live ranges are computed on // demand, so just skip any that haven't been computed yet. if (TargetRegisterInfo::isPhysicalRegister(Reg)) { for (MCRegUnitIterator Units(Reg, &TRI); Units.isValid(); ++Units) if (LiveInterval *LI = LIS.getCachedRegUnit(*Units))

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

Our architecture has 1-bit boolean predicate registers. I've defined comparison def NErrb : InstTCE<(outs I1Regs:$op3), (ins I32Regs:$op1,I32Regs:$op2), "", [(set I1Regs:$op3, (setne I32Regs:$op1, I32Regs:$op2))]>; But then I end up having the following bug: Code %0 = zext i8 %data to i32 %1 = zext i16 %crc to i32 %2 = xor i32 %1, %0 %3 = and i32 %2, 1 %4 =