Displaying 3 results from an estimated 3 matches for "builtin_init_trampoline".
2010 Oct 13
1
[LLVMdev] Intrinsic support
...gt;> I have no idea how to make use of llvm.invariant to help
>> devirtualization. If no use or other use case for them can be found,
>> maybe they should be removed.
>
> the dragonegg plugin uses llvm.invariant to help the code generators
> optimize the code it produces for builtin_init_trampoline. It writes
> some values into memory which is then constant forever after. Because
> pointers to this memory are passed into all kinds of functions, the
> optimizers don't understand that the values are constant without help,
> thus the use of llvm.invariant. It doesn't work...
2010 Oct 13
0
[LLVMdev] Missed devirtualization opportunities
Kenneth Uildriks wrote:
>> You're right, I hadn't thought this through. The whole point of making them
>> local is to say that "I'm sure these callees won't modify that memory"
>> regardless of what functions actually get called, even indirectly. We can't
>> know that they won't modify the vptr in advance, so invariant doesn't work
2010 Oct 13
3
[LLVMdev] Missed devirtualization opportunities
> You're right, I hadn't thought this through. The whole point of making them
> local is to say that "I'm sure these callees won't modify that memory"
> regardless of what functions actually get called, even indirectly. We can't
> know that they won't modify the vptr in advance, so invariant doesn't work
> here. Making it non-local just means