[LLVMdev] ValueTracking's GetUnderlyingObject vs. ScheduleDAGInstrs' getUnderlyingObject
baldrick at free.fr
Mon Oct 15 09:23:18 PDT 2012
> I'm investigating a problem with "Machine Instruction Scheduling" that is rooted
> in incorrect alias information.
> Things go wrong in the "Merge disjoint stack slots" pass when a store
> instruction fails to get updated after its stack slot is merged. As a result,
> when "Machine Instruction Scheduling" runs, it incorrectly re-orders the store
> and a subsequent load, thinking that they do not refer to the same underlying
> object when they actually do.
> The logic in "Merge disjoint stack slots" seems ok, except that it relies on
> llvm::GetUnderlyingObject to determine if an instruction needs to be updated.
it sounds to me like this logic is broken. For example, GetUnderlyingObject
has a recursion limit that will bail out if it has to look through too many
instructions to find the underlying object. Thus you can't ever rely on
GetUnderlyingObject actually finding the real underlying object. But it
sounds like "Merge disjoint stack slots" *is* relying on this (I don't know the
code, it's just the impression I get from your description).
> Unfortunately, unlike ScheduleDAGInstrs' getUnderlyingObject,
> llvm::GetUnderlyingObject doesn't handle ptrtoint instructions, and in this
> case, fails to see that the problematic store refers to the merged stack slot.
> It seems to me that the logic in ScheduleDAGInstrs's getUnderlyingObject should
> be pushed into llvm::GetUnderlyingObject. And indeed, when I do this, "Merge
> disjoint stack slots" correctly updates all of the instructions and "Machine
> Instruction Scheduling" behaves correctly.
> Is this the right thing to do? Would other callers to llvm::GetUnderlyingObject
> not want the additional behavior?
> Matthew Curtis.
>  http://llvm.org/docs/doxygen/html/StackColoring_8cpp_source.html
>  http://llvm.org/docs/doxygen/html/ValueTracking_8cpp_source.html#l01780
>  http://llvm.org/docs/doxygen/html/ScheduleDAGInstrs_8cpp_source.html#l00087
More information about the llvm-dev