On Nov 2, 2015, at 12:55 PM, Richard Sandiford <richard.sandif...@arm.com> wrote: > This was: > > ... Sometimes structure decls > have BLKmode but are assigned an integer-mode rtl (e.g. when passing > 3-byte structures by value to functions). > [...] > loc_descriptor refuses to use CONST_INT for BLKmode decls (which aren't > actually integers at the source level). That seems like the right > behaviour
I’ll plead ignorance here, but why do you think that? The dwarf standard says: There are six forms of constants. There are fixed length constant data forms for one, two, four and eight byte values (respec tively, DW_FORM_data1, DW_FORM_data2, DW_FORM_data4, and DW_FORM_data8). There ar e also variable length constant data forms encoded using LEB128 numbers (see below). Both signed (DW_FORM_sdata) and unsigned (DW_FORM_udata) variable length constants are available The data in DW_FORM_data1, DW _FORM_data2, DW_FORM_data4 and DW_FORM_data8 can be anything. Depending on c ontext, it may be a signed integer, an unsigned integer, a floating-point constant, or anything else. A consumer must use context to know how to interpret the bits, wh ich if they are target machine data (such as an integer or floating point constant) will be in target machine byte-order. Certainly supplying the known byte values of a constant is preferable to throwing up our hands and saying, I know, but I’m not telling. Given the text above, it seems like these forms can be used for content where the compiler knows the values of the bits that comprise the content. I’d ask, is the backing of your position supported by the dwarf standard? If yes, what part? I think you think that this describes the type, these do not. There is a separate system to describe the type. For example, DW_ATE_UTF describes the bytes as forming a UTF value. A wide int (or a CONST_INT) can be used to describe a unicode character, and it would have a DW_ATE_UTF encoding on it for the debugger to use to formulate an idea of how to display those bytes. Further, a mythical front end could have a 3 byte unicode character, and these can be modeless as there is no 3 byte machine mode for them. Code-gen would be BLKmode, the type would be DW_ATE_UTF, and one could form constants with CONST_INT. In a 152 bit UTF character in that front end, CONST_INT, generally speaking, isn’t big enough, so a CONST_WIDE_INT would be formed. The argument is the same. That a machine has a native 3 byte type or not, is of no consequence, so _any_ decision based upon the mode in this way is flawed. Then again, I don’t even pretend to be a language lawyer for the dwarf standard. :-)
