Displaying 6 results from an estimated 6 matches for "enterlocalvaluearea".
2011 Jul 11
3
[LLVMdev] RegAllocFast uses too much stack
...e time?
>
> This seems odd. I'd think that fast-isel should be able to materialize the constants when we want them rather than at the beginning of the block.
I'm not entirely sure why, but FastISel does intentionally materialize
constants at the beginning of the block. See
FastISel::enterLocalValueArea etc. Maybe Dan knows why?
-Eli
2011 Jul 11
0
[LLVMdev] RegAllocFast uses too much stack
...is seems odd. I'd think that fast-isel should be able to materialize the constants when we want them rather than at the beginning of the block.
>
> I'm not entirely sure why, but FastISel does intentionally materialize
> constants at the beginning of the block. See
> FastISel::enterLocalValueArea etc. Maybe Dan knows why?
Going bottom-up, FastISel doesn't know when it'll see the first use of a value
in a block. Cleverer schemes are possible.
Dan
2011 Jul 11
2
[LLVMdev] RegAllocFast uses too much stack
...#39;d think that fast-isel should be able to materialize the constants when we want them rather than at the beginning of the block.
>>
>> I'm not entirely sure why, but FastISel does intentionally materialize
>> constants at the beginning of the block. See
>> FastISel::enterLocalValueArea etc. Maybe Dan knows why?
>
>
> Going bottom-up, FastISel doesn't know when it'll see the first use of a value
> in a block. Cleverer schemes are possible.
Or less clever by not caching the result? :)
-eric
2011 Jul 11
0
[LLVMdev] RegAllocFast uses too much stack
...fast-isel should be able to materialize the constants when we want them rather than at the beginning of the block.
>>>
>>> I'm not entirely sure why, but FastISel does intentionally materialize
>>> constants at the beginning of the block. See
>>> FastISel::enterLocalValueArea etc. Maybe Dan knows why?
>>
>>
>> Going bottom-up, FastISel doesn't know when it'll see the first use of a value
>> in a block. Cleverer schemes are possible.
>
> Or less clever by not caching the result? :)
At least, we shouldn't cache stuff across f...
2011 Jul 11
0
[LLVMdev] RegAllocFast uses too much stack
On Jul 11, 2011, at 1:48 PM, Nick Lewycky wrote:
> I discovered recently that RegAllocFast spills all the registers before every function call. This is the root cause of one of our recursive functions that takes about 150 bytes of stack when built with gcc (same at -O0 and -O2, or 120 bytes at llc -O2) taking 960 bytes of stack when built by llc -O0. That's pretty bad for situations where
2011 Jul 11
4
[LLVMdev] RegAllocFast uses too much stack
I discovered recently that RegAllocFast spills all the registers before
every function call. This is the root cause of one of our recursive
functions that takes about 150 bytes of stack when built with gcc (same at
-O0 and -O2, or 120 bytes at llc -O2) taking 960 bytes of stack when built
by llc -O0. That's pretty bad for situations where you have small stacks,
which is not uncommon for