[llvm-commits] [llvm] r130485 - in /llvm/trunk: lib/Transforms/InstCombine/InstCombineShifts.cpp test/Transforms/InstCombine/shift.ll

Chris Lattner clattner at apple.com
Tue May 3 17:46:31 PDT 2011


On May 2, 2011, at 2:33 PM, Devang Patel wrote:

> Evan,
> 
> On May 2, 2011, at 2:00 PM, Evan Cheng wrote:
> 
>>> More generally, we don't want to sprinkle setDebugLoc calls into *every* instcombine xform.  We need a better solution.
>> 
>> I believe there is a long term plan being discussed. Devang, can you share what's being discussed so far?
> 
> As I understand, the long term plan being discussed will not help here. Instead, the plan assumes that all instructions and machine instruction will have DebugLoc. So in other words, the plan requires that we solve this particular issue first.

Ok.  Instcombine has an IRBuilder that it uses, changing xforms to use the IRBuilder is vastly preferable to using setDebugLoc everywhere.

> Without further delay, the plan being discussed seeks to find easier way to preserve debug values during code gen passes.
> 	- The idea is to make position of DBG_VALUE machine instructions in instruction stream irrelevant by using a new mechanism (we have not detailed what exactly, but it could be just another intrinsic or metadata pair or something else...) to pair a LLVM definition to respective source level variable information.  
> 	- At the end of compilation just before emitting out put, a super intelligent pass is employed to 
> 		a) look at variable info, 
> 		b) find corresponding value definitions, 
> 		c) find scopes and ranges of these definitions based on line number info attached with each machine instruction 
> 		d) construct complete debug info picture based on these information.
> 
> I am sure, others will correct me if I am missing something.

It's hard to really comment on this without more details, but as long as there aren't tons of new setDebugLoc calls in InstCombine, I'll be happy :)

-Chris



More information about the llvm-commits mailing list