[llvm-commits] [PATCH] Adding x32 ABI triple and separate StackSlotSize in MCAsmInfo

Eli Bendersky eliben at google.com
Fri Jan 18 15:10:08 PST 2013


On Fri, Jan 18, 2013 at 2:56 PM, Evan Cheng <evan.cheng at apple.com> wrote:
>
> On Jan 18, 2013, at 2:35 PM, Eli Bendersky <eliben at google.com> wrote:
>
>>>> Following David's email on llvmdev
>>>> (http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-January/058209.html),
>>>> here is an initial patch for adding the x32 ABI triple to LLVM.
>>>>
>>>> The patch is deliberately very simple. All it does is add the new
>>>> Triple::EnvironmentType value for the x32 ABI, and uses it on one
>>>> place - separating stack slot size and pointer size in MCAsmInfo. All
>>>> targets provide the same value there, but x86-64 has to behave
>>>> differently based on the ABI.
>>>> One place where this is important is the data alignment factor in
>>>> DWARF frame section. I discussed this with Rafael previosuly and we
>>>> agreed this solution makes sense.
>>>>
>>>> A limitation in our llvm-dwarfdump tool currently precludes me from
>>>> adding more tests that direct the slot size. I will try to see if I
>>>> can patch up llvm-dwarfdump to allow this separately. Once that
>>>> capability is in place, I will add more tests.
>>>>
>>>> Note that changes based on the x32 ABI will have to eventually
>>>> propagate into other places, but I will break it to small reviewable
>>>> and testable chunks over time. For the full picture of where this is
>>>> going, you can refer to the patches Michael Liao sent last year
>>>> (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-June/050360.html and
>>>> other threads).
>>
>>>> On Fri, Jan 18, 2013 at 1:56 PM, Evan Cheng <evan.cheng at apple.com> wrote:
>>> Hi Eli,
>>>
>>> What does "stack slot size" mean? Stack slots may not have the same size, depending on what objects are stored in them.
>>>
>>
>> Good question, and perhaps a more descriptive name for the
>> member/method can be found. The essential concept we're alluding to
>> here is the slot allotted for saving registers on the stack. The x32
>> ABI decouples register size from pointer size (which are equivalent on
>> x86 and on default x86-64). And yet, the x32 ABI requires to save the
>> full %rXX registers on the stack (section 3.2.1):
>>
>>    This subsection discusses usage of each register. Registers %rbp, %rbx and
>>    %r12 through %r15 “belong” to the calling function and the called
>> function is
>>    required to preserve their values. In other words, a called
>> function must preserve
>>    these registers’ values for its caller.
>>
>> The patch teaches MCDwarf to use the correct "slot" size in its frame
>> information output. To conclude, while previously the x86 target could
>> simply assume that the pointer size is what it needs, with x32 this is
>> no longer so, so a new concept is added. Would "RegisterStackSlotSize"
>> be a better / more descriptive name?
>
> It's theoretically possible to store smaller registers in smaller slots. Perhaps CalleeSaveStackSlotSize? Is it too long?
>

I don't think it's too long. And I don't think it's being used for
other purposes at this point, so the name you propose sounds fine.

> This change requires updates to out of tree targets, right? It might be worthwhile to send an email to llvm-dev as well.
>

Done.

Eli




More information about the llvm-commits mailing list