Displaying 4 results from an estimated 4 matches for "vfunction".
Did you mean:
function
2017 Apr 06
2
Dereferenceable load semantics & LICM
...rties are non local, so I don't see how
hoisting vptr load could be dangerous:
void foo(A& a) {
if (false)
a.foo();
}
will be:
void foo(A* dereferenceable(8) %a) {
if (false)
%vptr = load %a, !dereferenceable !{VtableSize, "GlobalProperty"},
!invariant.group !0
%vfunction = load %vptr, !invariant.load !0
call %vfunction();
}
and after hoisting:
void foo(A* dereferenceable(8) %a) {
%vptr = load %a, !dereferenceable !{VtableSize, "GlobalProperty"},
!invariant.group !{"GlobalProperty"}
%vfunction = load %vptr, !invariant.load !{"Globa...
2017 Apr 03
4
Dereferenceable load semantics & LICM
2017-04-01 15:59 GMT+02:00 Piotr Padlewski <piotr.padlewski at gmail.com>:
>
>
> 2017-03-31 23:20 GMT+02:00 Sanjoy Das <sanjoy at playingwithpointers.com>:
>
>> Hi Piotr,
>>
>> On March 31, 2017 at 1:07:12 PM, Piotr Padlewski
>> (piotr.padlewski at gmail.com) wrote:
>> > [snip]
>> > Do I understand it correctly, that it is legal to
2015 Aug 08
2
[cfe-dev] [LLVMdev] Clang devirtualization proposal
> I suspect #2 is the right design, mostly because I suspect most of the interesting and important inference cases are going to be cases where we can easily infer the stronger guarantee, and once inferred we will have much more freedom to optimize based on this stronger guarantee...
Can't the stronger guarantee be represented in the existing system by either:
* Adding 'readonly'
2017 Jan 20
4
RFC: Emitting empty invariant group for vtable loads
Hi all,
I would like to propose a new way clang would decorate vtable loads in
order to handle devirtualization better.
I've added *llvm-dev* also, because this can start a discussion about
changing invariant.group to just invariant.
PDF version of this RFC can be found here:
https://drive.google.com/file/d/0B72TmzNsY6Z8ZmpOUnB5dDZfSFU/view?usp=sharing
Background:
Initial old design: