llvm dev - Sep 2008 - [LLVMdev] Keeping values in memory

Hi all,

 

It looks like LLVM is quite eager to load values into registers when they
have multiple uses. Unfortunately, this increases register pressure,
specifically on x86. In my experience modern x86 processors are very capable
of using memory operands as source. In fact the only cases where a register
is preferred over repeatedly using the same memory operand is when multiple
instructions could use the value in the same clock cycle, or when it
significantly reduces code size.

 

I have found this to be mostly a concern with SIMD code (MMX and SSE). So if
anyone could tell me where to find the code that determines whether to load
a value into a register or leave it in memory, I could perform some tests to
see if a better heuristic exists.

 

Thanks,

 

Nicolas Capens

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080905/bed8c71a/attachment.html>

On Sep 5, 2008, at 7:06 AM, Nicolas Capens wrote:
> Hi all,
>
> It looks like LLVM is quite eager to load values into registers when  
> they have multiple uses. Unfortunately, this increases register  
> pressure, specifically on x86. In my experience modern x86  
> processors are very capable of using memory operands as source. In  
> fact the only cases where a register is preferred over repeatedly  
> using the same memory operand is when multiple instructions could  
> use the value in the same clock cycle, or when it significantly  
> reduces code size.
>
> I have found this to be mostly a concern with SIMD code (MMX and  
> SSE). So if anyone could tell me where to find the code that  
> determines whether to load a value into a register or leave it in  
> memory, I could perform some tests to see if a better heuristic  
> exists.
This is done in instruction selection. In general using registers over  
memory is preferred. I can see certain situations where keeping values  
in registers can end up hurting performance due to added spilling.  
However, a heuristic is never going to be satisfactory solution  
because it's guaranteed to miss important cases.

The right approach to combat this is implement generalized re- 
materialization in the register allocator. That'll come sometime  
(hopefully) next year when I rewrite the register allocator.

Evan

>
> Thanks,
>
> Nicolas Capens
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20080905/70e732db/attachment.html>