[llvm-commits] [llvm] r117667 - in /llvm/trunk: include/llvm/ include/llvm/CodeGen/ include/llvm/Target/ lib/CodeGen/ lib/CodeGen/SelectionDAG/ lib/Target/ARM/ lib/Target/Alpha/ lib/Target/Blackfin/ lib/Target/CBackend/ lib/Target/CellSPU/ lib/Ta

[John Thompson]

I did some investigation into some sizes, with the following results.

First some sizes of the items using vector:

ConstraintString = =*m,*m,~{dirflag},~{fpsr},~{flags}
visitInlineAsm stack size = 2120
sizeof(SDISelAsmOperandInfo) = 240
sizeof(AsmOperandInfo) = 104
sizeof(ConstraintInfo) = 56
vector<*> = 20

Next with some reduced SmallVector sizes:

 ConstraintString = =*m,*m,~{dirflag},~{fpsr},~{flags}
visitInlineAsm stack size = 14480
sizeof(SDISelAsmOperandInfo) = 672
sizeof(AsmOperandInfo) = 536
sizeof(ConstraintInfo) = 488
sizeof(SmallVector<SDISelAsmOperandInfo,5>) = 3376
sizeof(SmallVector<AsmOperandInfo,5>) = 2696
sizeof(SmallVector<ConstraintInfo,5>) = 2456
sizeof(SmallVector<SubConstraintInfo,2>) = 320
sizeof(SmallVector<std::string,4>) = 144

Note that I picked 5 for the main size for the constraint info structures
because with x86, the 3 clobbers always make the total constraint info count
5, and we want the typical case to not cause the SmallVector to switch to
dynamic.

Finally with the original SmallVector sizes:

ConstraintString = =*m,*m,~{dirflag},~{fpsr},~{flags}
stackSize = 53024
sizeof(SDISelAsmOperandInfo) = 1616
sizeof(AsmOperandInfo) = 1480
sizeof(ConstraintInfo) = 1432
sizeof(SmallVector<SDISelAsmOperandInfo,16>) = 25872
sizeof(SmallVector<AsmOperandInfo,16>) = 23696
sizeof(SmallVector<ConstraintInfo,16>) = 22928
sizeof(SmallVector<SubConstraintInfo,4>) = 1136
sizeof(SmallVector<std::string,8>) = 272

To approximate the stack frame size I used the difference between call
arguments in a run of a debug-built llc, i.e.

void dumpSizes(void *stackRefInner)
{
    printf("visitInlineAsm stack size = %d\n", (char*)stackRefInner -
(char*)&stackRefInner);
}

void SelectionDAGBuilder::visitInlineAsm(ImmutableCallSite CS) {
    dumpSizes(&CS);
...}


Question 1:

>From the above, it appears that reducing the SmallVector sizes to the
intermediate size used will get the visitInline stack frame size down to a
bit less than 16K.  So, would having the still somewhat largish 14.5K stack
frame be better than having the dynamic allocations otherwise done with
vector?  I'm thinking yes, because the heap activity is probably slower and
fragments memory.

Question 2:

If we wanted to look deeper into this, we'd probably want to look at timing
and heap activity.  I see that there is a Timer class that could be used
for measuring timing.  I didn't see a mechanism for tracking memory usage,
i.e the total allocations and frees, and peak memory usage.  Is there
something like this in there?

-John


On Fri, Oct 29, 2010 at 3:47 PM, John Thompson <
john.thompson.jtsoftware at gmail.com> wrote:

> If stack space is of concern, I think it would be safer to go back to
> vector.  Using vector will mean more heap allocations, but the overall
> memory usage would probably be less.
>
> How do you measure the stack space (i.e. is there a simple way besides
> inspection in the debugger)?  I'd like to measure both.
> -John
>   On Fri, Oct 29, 2010 at 2:22 PM, Dale Johannesen <dalej at apple.com>wrote:
>
>> Interesting.  It's true very small sizes are most common for these
>> vectors, but I wouldn't have expected the overhead to be that significant.
>>  Perhaps try lowering all the fixed allocations to 4?
>>
>>  On Oct 29, 2010, at 2:10 PMPDT, Nick Lewycky wrote:
>>
>> On 29 October 2010 10:29, John Thompson <
>> John.Thompson.JTSoftware at gmail.com> wrote:
>>
>>> Author: jtsoftware
>>> Date: Fri Oct 29 12:29:13 2010
>>> New Revision: 117667
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=117667&view=rev
>>> Log:
>>> Inline asm multiple alternative constraints development phase 2 -
>>> improved basic logic, added initial platform support.
>>>
>>
>> This change makes SelectionDAGBuilder::visitInlineAsm use up 30k of stack
>> space, largely due to the switch from std::vector to SmallVector. Please
>> fix!
>>
>>
>>
>
>
> --
>  John Thompson
> John.Thompson.JTSoftware at gmail.com
>
>


-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20101101/6abcab9c/attachment.html>