[LLVMdev] ValueTracking's GetUnderlyingObject vs. ScheduleDAGInstrs' getUnderlyingObject
arnolds at codeaurora.org
Mon Oct 15 09:26:03 PDT 2012
It seems to me that this is a bug in StackColoring. It should not
assume that GetUnderlyingObject always returns the underlying alloca
(it might fail for several reason - e.g. the default max lookup depth
// Climb up and find the original alloca.
00514 V = GetUnderlyingObject(V);
00515 // If we did not find one, or if the one that we found
is not in our
00516 // map, then move on.
00517 if (!V || !Allocas.count(V))
Instead of continuing, it should probably clean the Memory Operand so
that future alias queries will return a conservative result.
On Mon, Oct 15, 2012 at 11:00 AM, Matthew Curtis <mcurtis at codeaurora.org> wrote:
> Hello all.
> 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
> 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
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
> The Linux Foundation
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev