[LLVMdev] ValueTracking's GetUnderlyingObject vs. ScheduleDAGInstrs' getUnderlyingObject
mcurtis at codeaurora.org
Mon Oct 15 09:00:05 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. 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?
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
More information about the llvm-dev