On Wed, Dec 18, 2013 at 1:39 PM, Jan Hubicka wrote:
>> > OK, so the explanation is not as simple as claim that non-POD types
>> > needs to be constructed or copied by constructor and C++ FE always
>> > generate an explicit vtbl store?
>>
>> No as optimizers may combine stores for example.
>
> Yep,
> > OK, so the explanation is not as simple as claim that non-POD types
> > needs to be constructed or copied by constructor and C++ FE always
> > generate an explicit vtbl store?
>
> No as optimizers may combine stores for example.
Yep, I understand we can design "evil" optimization that will ma
On Mon, Dec 16, 2013 at 2:58 PM, Jan Hubicka wrote:
>> Hi,
>>
>> On Sat, Dec 14, 2013 at 11:01:53PM +0100, Jan Hubicka wrote:
>> > Hi,
>> > this patch makes stmt_may_be_vtbl_ptr_store to skip clobbers as discussed
>> > previously.
>>
>> This is the first time I hear about this but the change is ob
> Hi,
>
> On Sat, Dec 14, 2013 at 11:01:53PM +0100, Jan Hubicka wrote:
> > Hi,
> > this patch makes stmt_may_be_vtbl_ptr_store to skip clobbers as discussed
> > previously.
>
> This is the first time I hear about this but the change is obviously
> OK, thanks.
It actually seems to solve quite num
Hi,
On Sat, Dec 14, 2013 at 11:01:53PM +0100, Jan Hubicka wrote:
> Hi,
> this patch makes stmt_may_be_vtbl_ptr_store to skip clobbers as discussed
> previously.
This is the first time I hear about this but the change is obviously
OK, thanks.
> Martin, I do not fully follow the logic of this func
Hi,
this patch makes stmt_may_be_vtbl_ptr_store to skip clobbers as discussed
previously.
Martin, I do not fully follow the logic of this function. Can't we just
ignore all stores that are not of pointer type that looks like vptr
type? All those tores are compiler generated and we probably can ju
