[DTrace-devel] Reviewed: Do not hard-code the temp register in aggregation functions

Eugene Loh eugene.loh at oracle.com
Wed Nov 25 17:34:48 PST 2020


On 11/20/2020 02:15 PM, kris.van.hees at oracle.com wrote:
> [Commit 15efba57c50081ecba70bc236cb25f619c3f1c48]
>> Do not hard-code the temp register in aggregation functions
>>
>> A few aggregation functions were hard-coding the temp register
>> to BPF_REG_0.  Let dt_regset_alloc() pick the register.
> Actually, for code that needs to use a short-term temporary register, %r0
> is an ideal choice as long as you do not make any function calls or call
> dt_cg_node() to generate code for a subtree.  So, using it as a scratch
> register is perfectly fine, and often preferred because it reduces the
> pressure on the dynamically allocated registers.
I'm confused.  Are you saying you're against this patch? Presumably, in 
these functions, we do not know which registers are currently in use.  
Presumably, that is why we explicitly dt_regset_xalloc(BPF_REG_0) here.  
(In contrast, there are places we assume we know what the register usage 
is, and we hardcode register usage without regset alloc/free at all.)  
So, it seems to me the code would be more robust if we ask 
regset_alloc() to give us a free register rather than specifying which 
register to give us.  That induces no register pressure since it's going 
to give us a register that's free.  Our reasoning about which registers 
are free could be faulty;  in contrast, regset knows which registers are 
free.



More information about the DTrace-devel mailing list