[llvm] r175023 - Debug Info: LiveDebugVarible can remove DBG_VALUEs, make sure we emit them back.

[Jakob Stoklund Olesen]

On Feb 12, 2013, at 6:37 PM, Eric Christopher <echristo at gmail.com> wrote:

> For function parameters this is still somewhat of a hack. The correct way to fix this is to change the representation we use for function arguments to use the incoming value and track that for location information - it would obviate the need to scan through the function collecting function parameters as if they were local variables.

The problem is that in C, arguments are variables, so we can't simply track the incoming value. The variable could be reassigned.

Unless DWARF can track the incoming argument value separately from the current variable value?

> Also, it shouldn't depend upon whether or not we're enabling misched or not, a simple testcase should be an unused parameter and dce.
> 
> +define void @Proc8(i32* nocapture %Array1Par, [51 x i32]* nocapture %Array2Par, i32 %IntParI1, i32 %IntParI2) nounwind optsize ssp uwtable {
> 
> You also shouldn't need ssp/uwtable on this.
>  
>>  class LiveDebugVariables : public MachineFunctionPass {
>>    void *pImpl;
>> +  /// Whether emitDebugValues is called.
>> +  bool EmitDone;
>> +  /// Whether the machine function is modified during the pass.
>> +  bool ModifiedMF;
> 
>  Any reason why these aren't going into the pass impl?
> 
> Jakob: It looks like we don't need the value renaming machinery any more, i.e.
> 
> void LiveDebugVariables::renameRegister(unsigned OldReg, unsigned NewReg, unsigned SubIdx)
> 
> since I'm guessing the register allocator keeps the virtual register map up to date that we use later when we actually run the pass?

If the code is really dead, it's fine to delete it. RA uses other LDV functions when spilling and splitting live ranges.

/jakob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130212/c2446fb3/attachment.html>