[PATCH] Cleanup and document MachineLocation

Eric Christopher echristo at gmail.com
Fri Apr 26 15:16:38 PDT 2013


That looks totally reasonable.

Yeah, cleanup, maybe a couple of specific tests for it and fix the
misspelling of convention that's somewhere in there ;)

-eric

On Fri, Apr 26, 2013 at 11:01 PM, Adrian Prantl <aprantl at apple.com> wrote:
>
> 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
>




More information about the llvm-commits mailing list