search for: getunderlyingobjectsforinstr

...safeMemoryObject returns true, resulting in > the edge being added. Maybe someone can shed some light as to why > the call to isIdentifedMemoryObject in isUnsafeMemoryObject is needed > if we are using AA. I think that it might not be needed. Here's my thinking: There is a call to getUnderlyingObjectsForInstr, and that needs to be there because of how the calling code groups the resulting SUs by underlying object. Specifically, ScheduleDAGInstrs::buildSchedGraph first gets the underlying objects for a value, and then only calls addChainDependency on SUs that share one of these underlying objects. The re...

Hi, I write again regarding buildSchedGraph(), as I am still not happy about things there. I have found at least two examples which do not work out: 1) SU(2) Store "Value A" SU(1) Store "Value A" SU(0) Load "Value A" If MIsNeedChainEdge() returns false for SU(0) and SU(1), SU(0) is inserted into RejectedMemNodes and removed from its MemUses SU list, as this

...x6e02518>) and %W0<def> = LDRSBWui %X0<kill>, 1; mem:LD1[%scevgep101](tbaa=<0x6e02518>) instructions. AFAICT, the problem is that the Values associated with the MI's memory operands are used to determine the underlying objects accessed by a memory operation (See getUnderlyingObjectsForInstr() in ScheduleDAGInstrs.cpp). In turn the dependency analysis relies on these Values. When the STRBBui is merged into BB#16 it is derived from BB#15. Thus, the STRBBui associated Value is 'C'. The dependency analysis detects the dependency on array 'C', but misses the dependency...

...lting in > > the edge being added. Maybe someone can shed some light as to why > > the call to isIdentifedMemoryObject in isUnsafeMemoryObject is > > needed if we are using AA. > > I think that it might not be needed. Here's my thinking: > > There is a call to getUnderlyingObjectsForInstr, and that needs to be > there because of how the calling code groups the resulting SUs by > underlying object. Specifically, ScheduleDAGInstrs::buildSchedGraph > first gets the underlying objects for a value, and then only calls > addChainDependency on SUs that share one of these und...

Hello, While tuning the MIScheduler for my target, I discovered a code that unnecessarily restricts the scheduler. I think this is a bug, but I would appreciate a second opinion. In file ScheduleDAGInstrs.cpp, the function MIsNeedChainEdge determines whether two MachineInstrs are ordered by a memory dependence. It first runs through the standard criteria (Do both instructions access memory?