Displaying 3 results from an estimated 3 matches for "indirectuser".
2015 Oct 10
2
[RFC] Clean up the way we store optional Function data
...data. We create N
different ReturnInsts to point to the same thing. I think that's wasteful.
4. These hidden ReturnInsts effectively make a Function an indirect user of
its optional data. This relationship should be made explicit to avoid bugs.
Proposal: Introduce a new Constant, llvm::IndirectUser
======================================================
This is my take on Duncan's proposed solution to PR24755 [1].
It involves creating a new type of Constant. A sketch:
struct llvm::IndirectUser : llvm::Constant {
Constant *Data; // Operand 0
unsigned RefCount; //...
2015 Oct 21
2
[RFC] Clean up the way we store optional Function data
...s that use C++ exceptions
> and build with LTO, but even there it's a per-function overhead. I
> doubt it really matters.
>
>> If not, maybe we could leave personality function handling untouched and add a "Constant **OptionalData" array to Function.
>
> The `IndirectUser` approach you outlined initially might be better
> than this?
>
>> vedant
>>
>>
>>> On Oct 14, 2015, at 3:12 PM, Vedant Kumar <vsk at apple.com> wrote:
>>>
>>> I like the idea of using hung off uses.
>>>
>>> We can keep...
2015 Oct 16
2
[RFC] Clean up the way we store optional Function data
Here is a WIP patch as promised:
http://reviews.llvm.org/D13829
It uses a hungoff uselist to store optional data as needed.
Some early objections from Duncan:
- An extra one-time malloc() is required to set personality functions.
- We get and set personality functions frequently. This patch introduces a level of indirection which slows the common case down.
Is this overhead