search for: getunderlyingobjectforinstr

...llvm.org/bugs/show_bug.cgi?id=13891. That appears to have been a red herring; I believe the value of -1 is an artificial dependency indicating the scheduling barrier at the end of the group, or something along those lines. The problem appears to be that the load and store both return a value from getUnderlyingObjectForInstr, but they are two different objects... Thanks, Bill > > Thanks, > Bill > > On Fri, 2012-09-21 at 11:15 -0500, Sergei Larin wrote: > > Hi Bill, > > > > Which scheduler do you use? MI or SDNode one? In either case the problem > > is likely the same, but...

...13891. > > That appears to have been a red herring; I believe the value of -1 is an > artificial dependency indicating the scheduling barrier at the end of > the group, or something along those lines. The problem appears to be > that the load and store both return a value from > getUnderlyingObjectForInstr, but they are two different objects... > > Thanks, > Bill > > > > > Thanks, > > Bill > > > > On Fri, 2012-09-21 at 11:15 -0500, Sergei Larin wrote: > > > Hi Bill, > > > > > > Which scheduler do you use? MI or SDNode one? I...

...o ($sp + 44) and ($sp + 40), and instruction LDC1 loads from ($sp + 40), there should be a dependency between these instructions. However, when ScheduleDAGInstrs::BuildSchedGraph(AliasAnalysis *AA) builds the schedule graph, there are no dependency edges added between the two SWs and LDC1 because getUnderlyingObjectForInstr returns different objects for these instructions: underlying object of SWs: FixedStack-1 underlying object of LDC1: struct.ObjPointStruct* %P Is this a bug? Or are there ways to tell BuildSchedGraph it should add dependency edges?

...idden and randomly popping bugs. So the question much more likely is: Why AA sees these two objects as not aliasing, and are they properly described and presented to it? Does ld/bitcast has proper memory operands? Any flags on them? Is underlying memory object making sense? You can look at getUnderlyingObjectForInstr and MIsNeedChainEdge in the MI scheduling framework to see what I mean. If you are still using SDNode scheduling framework - it has a very similar functionality in a slightly different code. Hope this helps. Sergei --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hoste...

...gt; So the question much more likely is: Why AA sees these two objects as not > aliasing, and are they properly described and presented to it? > > Does ld/bitcast has proper memory operands? Any flags on them? Is > underlying memory object making sense? > > You can look at getUnderlyingObjectForInstr and MIsNeedChainEdge in the MI > scheduling framework to see what I mean. > > If you are still using SDNode scheduling framework - it has a very similar > functionality in a slightly different code. > > Hope this helps. > > Sergei > > --- > Qualcomm Innovati...

...gt; instruction LDC1 loads from ($sp + 40), > there should be a dependency between these instructions. > > However, when ScheduleDAGInstrs::BuildSchedGraph(AliasAnalysis *AA) > builds the schedule graph, > there are no dependency edges added between the two SWs and LDC1 because > getUnderlyingObjectForInstr returns different objects for these instructions: > > underlying object of SWs: FixedStack-1 > underlying object of LDC1: struct.ObjPointStruct* %P > > > Is this a bug? > Or are there ways to tell BuildSchedGraph it should add dependency edges? This is a wild guess. But it...

...ads from ($sp + 40), >> there should be a dependency between these instructions. >> >> However, when ScheduleDAGInstrs::BuildSchedGraph(AliasAnalysis *AA) >> builds the schedule graph, >> there are no dependency edges added between the two SWs and LDC1 because >> getUnderlyingObjectForInstr returns different objects for these instructions: >> >> underlying object of SWs: FixedStack-1 >> underlying object of LDC1: struct.ObjPointStruct* %P >> >> >> Is this a bug? >> Or are there ways to tell BuildSchedGraph it should add dependency edges? >...

...>> there should be a dependency between these instructions. >>> >>> However, when ScheduleDAGInstrs::BuildSchedGraph(AliasAnalysis *AA) >>> builds the schedule graph, >>> there are no dependency edges added between the two SWs and LDC1 because >>> getUnderlyingObjectForInstr returns different objects for these instructions: >>> >>> underlying object of SWs: FixedStack-1 >>> underlying object of LDC1: struct.ObjPointStruct* %P >>> >>> >>> Is this a bug? >>> Or are there ways to tell BuildSchedGraph it sho...

...ld be a dependency between these instructions. >>>> >>>> However, when ScheduleDAGInstrs::BuildSchedGraph(AliasAnalysis *AA) >>>> builds the schedule graph, >>>> there are no dependency edges added between the two SWs and LDC1 because >>>> getUnderlyingObjectForInstr returns different objects for these instructions: >>>> >>>> underlying object of SWs: FixedStack-1 >>>> underlying object of LDC1: struct.ObjPointStruct* %P >>>> >>>> >>>> Is this a bug? >>>> Or are there ways to te...

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:

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