Support for HiPE-compatible code emission

[Eli Bendersky]

>> Tests indicate that you care about the x32 ABI, where sometimes you want
>> to
>> know the data model and not the platform bitness. This applies to stack
>> slot
>> size and to registers used for addresses. How does this affect your code?
>>
>
> I'm not sure I get your question here. Let me clarify what I actually care
> about as this misunderstanding might be a result of my abuse of the LLVM
> API:
>
>
>> +  const unsigned Guaranteed = HipeLeafWords * SlotSize;
>> +  const unsigned CallerStkArity =
>> +    std::max<int>(0, MF.getFunction()->arg_size() - CCRegisteredArgs);
>> +  unsigned MaxStack =
>> +    MFI->getStackSize() + CallerStkArity * SlotSize + SlotSize;
>>
>
> I 'd like to compute some metrics (such as the above) based on the number of
> *bytes* that are occupied on the stack for some values (e.g., the number of
> bytes that are used on the stack for the arguments of a function). One way
> to do that (that seemed reasonable to me :-)) was to use the pointer-size
> (or word-size or slot-size). So, what I only care about is the platform
> bitness. Is there a better way to write that? :-)
>

Intel 64-bit CPUs can have a x32 mode in which pointers are 4 bytes
long. Therefore, when you want the stack slot size, there's another
getter for that now and you should not rely on the identity "stack
size == pointer size". See some of the others tests that trigger the
x32 ABI in upstream trunk.


> A couple of small fixes here, too; they shouldn't be a problem.
>
> Is this OK to commit?
>

Thanks for the fixes. I'm not the authority for final approvals in
this region though. Nadav or someone else should give you the green
light if they're OK with the patch.

Eli