Bernhard Reutner-Fischer via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
> On 7 March 2023 07:21:23 CET, juzhe.zh...@rivai.ai wrote:
>>From: Ju-Zhe Zhong <juzhe.zh...@rivai.ai>
>>
>
>>+class vleff : public function_base
>>+{
>>+public:
>>+ unsigned int call_properties (const function_instance &) const override
>>+ {
>>+ return CP_READ_MEMORY | CP_WRITE_CSR;
>>+ }
>>+
>>+ gimple *fold (gimple_folder &f) const override
>>+ {
>>+ /* fold vleff (const *base, size_t *new_vl, size_t vl)
>>+
>>+ ====> vleff (const *base, size_t vl)
>>+ new_vl = MEM_REF[read_vl ()]. */
>>+
>>+ auto_vec<tree, 8> vargs;
>
> Where is that magic 8 coming from?
I'm probably not saying anything you don't already know, but:
The second template parameter is just an optimisation. It reserves a
"small" amount of stack space for the vector, to reduce the likelihood
that a full malloc/free will be needed. The vector can still grow
arbitrarily large.
So these numbers are always just gut instinct for what a reasonable
common case would be. There's no particular science to it, and no
particular need to explain away the value.
The second parameter is still useful if the vector size is known at
construction time.
When I've looked at cc1 and cc1plus profiles in the past, malloc has
often been a significant contributor. Trying to avoid malloc/free
cycles for "petty" arrays seems like a worthwhile thing to do.
Thanks,
Richard
