search for: stackcoloring_8cpp_sourc

...lots" 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? Thanks, Matthew Curtis. [1] http://llvm.org/docs/doxygen/html/StackColoring_8cpp_source.html [2] http://llvm.org/docs/doxygen/html/ValueTracking_8cpp_source.html#l01780 [3] http://llvm.org/docs/doxygen/html/ScheduleDAGInstrs_8cpp_source.html#l00087 -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

...e::f"* %tmp to { <2 x float>, <2 x float> }* ... ret void *Steps to reproduce:* For debugging purposes, I have modified last few lines of runOnMachineFunction(..) method present in the StackColoring.cpp file. The original source can be found here: https://llvm.org/doxygen/StackColoring_8cpp_source.html bool StackColoring::runOnMachineFunction(MachineFunction &Func) { ... ... remapInstructions(SlotRemap); + bool markerCount = removeAllMarkers(); + DenseMap<int, int>::iterator itr = SlotRemap.begin(); + const AllocaInst *dInst = MFI->getObjectAllocation(itr...

...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? > > Thanks, > Matthew Curtis. > > [1] http://llvm.org/docs/doxygen/html/StackColoring_8cpp_source.html > [2] http://llvm.org/docs/doxygen/html/ValueTracking_8cpp_source.html#l01780 > [3] http://llvm.org/docs/doxygen/html/ScheduleDAGInstrs_8cpp_source.html#l00087 >

Caldarale, Charles R schrieb: > You have not provided us with the declaration for f(). Unless its argument is marked with the nocapture attribute, the compilation of g() cannot assume that f() has not retained a pointer to the x struct and is using it in the second call. > thanks a lot for the input. Yes, I forgot to that. The C function declaration would have been void f( struct a_b