[Dwarf-Discuss] Representing the location of smaller values in vector registers

[Cary Coutant]

>> Sorry, Michael, but you're just muddying the waters. The
>> data_bit_offset attribute is used only when "the value of an object of
>> the given type does not fully occupy the storage described by a byte
>> size attribute." That is not the case here -- the original question
>> was about a value of a type that does not fully occupy a register,
>> which is a totally different question. We're just not going to expect
>> (nor is it even physically possible in the DWARF representation) that
>> the producer invent a different base type for each possible location
>> where a variable might be stored. Whether it's a single location or a
>> location list is irrelevant to the question, but the possibility that
>> there may be a location list is what exposes the impracticality of
>> your suggestion -- a variable can have only a single type, regardless
>> of how many location list entries it has.
>
> The DWARF did not include a location list.

No, it didn't, and I don't know why you keep suggesting that it makes
a difference. Whether a variable has a single location or a list of
locations depends solely on what kinds of optimizations occur.
Everyone understands that. The only reason location lists entered the
discussion was because you claimed that the placement of the value in
a register could be described with the data_bit_offset attribute in
the base type. That might seem plausible at first, but breaks down as
soon as you consider what happens when you do have a location list --
you'd need one base type to describe the variable when it's in a
larger register, and another base type to describe it when it's not.
This is what David and the others were trying to point out.

> Adrian's DWARF, as written, describes a variable allocated to a register.
> Apparently permanently, or at least, within the current scope.  (I've seen
> this in embedded code where a variable is assigned to a register.)  What
> was likely intended is a location list which specifies where the variable's
> *value* may be found, independent of where the variable was allocated.

It's a simple example. It's perfectly plausible for a variable to live
its entire lifetime in a single register. But when it does, the
placement of the value in that register is *not* to be described with
a data_bit_offset attribute in its base type. That wouldn't work, and
it's not what that attribute is for.

> Many optimizations eliminate allocating storage for a variable.  When this
> happens, there isn't a DW_AT_location attribute.

Irrelevant.

> If there had been a location list in Adrian's DWARF, the discussion about
> location lists and how ABIs tell you how to interpret them might have been
> on point.  Without a location list, I don't see the relevance.

As I said, location lists only came up as a counter-example to your
suggestion to use the data_bit_offset attribute of the base type.

We're not discussing "how ABIs tell you how to interpret [location
lists]". We're discussing whether the consumer is expected to turn to
the ABI to find out how a smaller value is stored in a larger
register. It's relevant with or without a location list. It's relevant
to any register location description, whether in a single location
description or a location list, whether in a simple location
description or a compound location description.

> An ABI defines loading a value into a register from memory.  No one
> (certainly not me) is trying to define those rules in DWARF.

Good.

>> The source of the original uncertainty about representation of a
>> smaller value in a larger register is probably that the DWARF spec
>> *does* explicitly state, for DW_OP_piece, if "the piece is located in
>> a register, but does not occupy the entire register, the placement of
>> the piece within that register is defined by the ABI." But we make no
>> such similar claim for simple register location descriptions. That led
>> Adrian to wonder if he should be using DW_OP_piece. I think it's an
>> oversight, easily clarified.
>
> There are no DWARF expressions involved here.  What does the
> description of DW_OP_piece have to do with a DWARF description
> which doesn't use a DWARF expression?

[I saw your followup, but it doesn't change the answer...]

Adrian was looking for guidance to understand what the spec says about
placement of smaller values in larger registers. He found some
guidance in the section on DW_OP_piece, but nowhere else, leading him
to ask if clang should have been using DW_OP_piece to describe this
case. That simple statement under DW_OP_piece should also apply under
the DW_OP_reg operators, and if it had been there, it would have been
much clearer that DW_OP_piece is totally unnecessary for his example.

-cary