Hi Jan,
>> Hi Jan,
>>
>> >* g++.dg/lto/alias-3_0.C: New file.
>> >* g++.dg/lto/alias-3_1.c: New file.
>>
>> the new test has a couple of problems: DejaGnu warns everywhere:
>>
>> WARNING: lto.exp does not support dg-lto-do in secondary source files
>> WARNING: lto.exp does not support d
> Hi Jan,
>
> > * g++.dg/lto/alias-3_0.C: New file.
> > * g++.dg/lto/alias-3_1.c: New file.
>
> the new test has a couple of problems: DejaGnu warns everywhere:
>
> WARNING: lto.exp does not support dg-lto-do in secondary source files
> WARNING: lto.exp does not support dg-lto-options in
Hi Jan,
> * g++.dg/lto/alias-3_0.C: New file.
> * g++.dg/lto/alias-3_1.c: New file.
the new test has a couple of problems: DejaGnu warns everywhere:
WARNING: lto.exp does not support dg-lto-do in secondary source files
WARNING: lto.exp does not support dg-lto-options in secondary sou
On 9 July 2019 15:37:30 CEST, Richard Biener wrote:
>On Tue, 9 Jul 2019, Jan Hubicka wrote:
>
>> Hi,
>> this is updated variant I am testing.
>> It documents better how function works and streamlines the checks.
>>
>> OK assuming it passes the tests?
>>
>> Honza
>>
>> Index: tree-ssa-alias.c
>>
On Tue, 9 Jul 2019, Jan Hubicka wrote:
> Hi,
> this is updated variant I am testing.
> It documents better how function works and streamlines the checks.
>
> OK assuming it passes the tests?
>
> Honza
>
> Index: tree-ssa-alias.c
>
Hi,
this is updated variant I am testing.
It documents better how function works and streamlines the checks.
OK assuming it passes the tests?
Honza
Index: tree-ssa-alias.c
===
--- tree-ssa-alias.c(revision 273193)
+++ tree-ssa-a
On Tue, 9 Jul 2019, Jan Hubicka wrote:
> > > tree_int_cst_equal will return false if offsets are not INTEGER_CST.
> > > I was not sure if I can safely use operand_equal_p. What happens for
> > > fields with variable offsets when I inline two copies of same function
> > > which takes size as param
> > tree_int_cst_equal will return false if offsets are not INTEGER_CST.
> > I was not sure if I can safely use operand_equal_p. What happens for
> > fields with variable offsets when I inline two copies of same function
> > which takes size as parameter and make the size different? Will I get
> >
On Tue, 9 Jul 2019, Jan Hubicka wrote:
> > For consistency yes I guess but IIRC they cannot really appear in
> > FIELD_DECLs.
>
> OK, i tought that if I put SVE into structures, we may end up with
> these.
> > > + /* Different fields of the same record type cannot overlap.
> > > + ??? Bitf
> For consistency yes I guess but IIRC they cannot really appear in
> FIELD_DECLs.
OK, i tought that if I put SVE into structures, we may end up with
these.
> > + /* Different fields of the same record type cannot overlap.
> > +??? Bitfields can overlap at RTL level so punt on them. */
On Tue, 9 Jul 2019, Jan Hubicka wrote:
> Hi,
> this is updated patch. I based the logic on gimple_compare_field_offset but
> dropped bits about PLACEHOLDER_EXPR since my understanding is that to get
> comparsion done I would then need to compare operand #2 of COMPONENT_REF which
> I don't.
>
> I
Hi,
this is updated patch. I based the logic on gimple_compare_field_offset but
dropped bits about PLACEHOLDER_EXPR since my understanding is that to get
comparsion done I would then need to compare operand #2 of COMPONENT_REF which
I don't.
I also wrote the range checks using polyint since I bel
> > +/* FIELD1 and FIELD2 are two component refs whose bases are either
> > + both at the same address or completely disjoint.
> > + Return 1 if FIELD1 and FIELD2 are non-overlapping
> > + Return 0 if FIELD1 and FIELD2 are having same addresses or are
> > + completely disjoint.
>
> compl
On Mon, 8 Jul 2019, Jan Hubicka wrote:
> Hi,
> this patch avoids == compare of main varinats in nonoverlapping_component_refs
> making them work on unmerged type (such as when one is C++ ODR and other is
> C).
> This is not hard to do
>- nonoverlapping_component_refs_since_match is
> -fn
Hi,
this patch avoids == compare of main varinats in nonoverlapping_component_refs
making them work on unmerged type (such as when one is C++ ODR and other is C).
This is not hard to do
- nonoverlapping_component_refs_since_match is
-fno-strict-aliasing safe and only cares about type sizes/
15 matches
Mail list logo
