[PATCH] Cleanup and document MachineLocation

[Adrian Prantl]

On Apr 26, 2013, at 2:31 PM, Eric Christopher <echristo at gmail.com> wrote:

> On Fri, Apr 26, 2013 at 10:27 PM, Adrian Prantl <aprantl at apple.com> wrote:
>> PATCH:
>> Cleanup and document MachineLocation. Clarify documentation and API to make the difference between direct and indirect locations more explicit.
>> 
>> It also makes a shortcoming of the current design more visible:
>> Currently we use an offset of 0 in a DBG_VALUE to indicate generate a direct register value. There appears to no way to specify an indirect value with offset 0 (a breg+0 in dwarf). If you agree with this diagnosis, I’ve got a second (more invasive) patch to the machine layer waiting that rectifies this situation.
>> 
>> thanks,
>> Adrian
>> 
>> PS: Eric, if you want to look into this this is a lower priority item than my other patches.
>> 
> 
> Heh. This one was trivial. Have at.

Thanks! Then you can look forward to the monstrosity that’s coming to repair this :-)
I was planning to clean this up a little before moving forward, but it might be interesting to hear you opinion on the design beforehand:

[PATCH 2/2] Change the informal convention of DBG_VALUE so that we
 can also express a register-indirect address with an offset of 0. It used to be
 that a DBG_VALUE is a register-indirect value if the offset (operand 1) is
 nonzero. The new convention is that a DBG_VALUE is register-indirect if the
 first operand is a register and the second operand is an immediate. For plain
 registers we use the combination reg, reg (anything non-imm).

Not very elegant, but we are already using the operand types to convey information about the storage so I thought that would be closest to the existing design and the least invasive solution.

thanks,
Adrian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Change-the-informal-convention-of-DBG_VALUE-so-that-.patch
Type: application/octet-stream
Size: 19570 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130426/c3de5927/attachment.obj>