Scheduling question (memory dependency)

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

Example source code is as follows:

Here's another data point that may be useful. [Scheduling experts,
please help! :slight_smile: ]

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:

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. If that decision is wrong, you will end up with a
well hidden 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

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
13891 – [ppc64] Incorrect code when passing small bitfield parameters at -O1 and above.

Thanks,
Bill

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
13891 – [ppc64] Incorrect code when passing small bitfield parameters at -O1 and above.

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

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.

Bill,

  I am not sure what do you mean by "is not acting as a chain for loads and stores"...
  There is probably a reason why those mem ops are not in AliasChain. Do you know what is that reason? Are they marked as invariant for instance?
  If getUnderlyingObjectForInstr really think they are the same object, and they are not, there probably would be a false edge, but you are missing one...

Sergei