[LLVMdev] alloc_size metadata

[Duncan Sands]

Hi Nuno,

>>> This is actually non-trivial to accomplish.
>>> Metadata doesn't count as a user, so internal functions with no
>>> other usage will get removed.
>>
>> I thought that it is possible to have passes run before the optimizer
>> performs such deletions. Is this not practical? Another option is to
>> change the current implementation delete such functions in two phases:
>> in the first phase we leave functions with metadata references. In the
>> second phase (which runs near the end of the pipeline) we delete
>> functions regardless of metadata references.
>
> Right now, if you list the users of a Value, the references coming
> from metadata won't appear. Metadata is not an user and doesn't count
> towards the number of uses of a value.  That's why using anything
> about constant expressions risks disappearing.
> Leaving non-used functions to be removed after all optimizations could
> be done. But then you would probably want to, for example, patch the
> pass manager so that it didn't run a function pass over dead
> functions, and so on.

the functions could be declared to have linkonce_odr linkage.  That way
they will be zapped after the inliner runs, but shouldn't be removed
before.

>>> Another thing that bothers me is the implementation on the
>>> objectsize intrinsic. This intrinsic returns the *constant* size of
>>> the pointed object given as argument (if the object has a constant
>>> size). However, with this function scheme, the implementation would
>>> be a bit heavy, since it would need to inline the @lo and @hi
>>> functions, simplify the resulting expression, and then check if the
>>> result is a ConstantInt. And remember that in general these functions
>>> can be arbitrary complex.
>>
>> I agree; we'd need to use SCEV or some other heavyweight mechanism to
>> do the analysis. In some sense, however, that would be the price of
>> generality. On the other hand, I see no reason why we could not write a
>> utility function that could accomplish all of that, so we'd only need
>> to work out the details once.
>
> SCEV is not the answer here. You just want to know if the result of a
> function is constant given a set of parameters. Inlining +
> simplifications should do it.  But doing an inlining trial is expensive.

The hi/lo functions could be declared always_inline.  Thus they will always
be inlined, either by the always-inliner pass or the usual one.  You would
need to insert the instrumentation code or whatever that uses hi/lo before
any inliner runs, and run optimizations such as turning objectsize into a
constant after the inliner runs.

Ciao, Duncan.