Re: Do not use TYPE_CANONICAL in useless_type_conversion

> Jan Hubicka writes: > > > Does the patch in https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00902.html > > help? > > No, it doesn't. > Andreas, I am sorry for getting late to this. I hoped that the alternative patch by Alexandre would fix this. I still don't know how to

Re: Do not use TYPE_CANONICAL in useless_type_conversion

Jan Hubicka writes: >> Jan Hubicka writes: >> >> > Does the patch in https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00902.html >> > help? >> >> No, it doesn't. >> > Andreas, > I am sorry for getting late to this. I hoped that the alternative patch by >

Re: Do not use TYPE_CANONICAL in useless_type_conversion

On Oct 14, 2015, Jan Hubicka wrote: >> On Oct 13, 2015, Eric Botcazou wrote: >> >> > Note that this is PR middle-end/67912. >> >> Thanks. I added this piece of information to the ChangeLog entry, and >> checked the patch in. > Thanks, Alexandre. That

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> On Oct 13, 2015, Eric Botcazou wrote: > > > Note that this is PR middle-end/67912. > > Thanks. I added this piece of information to the ChangeLog entry, and > checked the patch in. Thanks, Alexandre. That indeed looks better than my variant of the patch. Does it also

Re: Do not use TYPE_CANONICAL in useless_type_conversion

On Tue, 13 Oct 2015, Alexandre Oliva wrote: > On Oct 9, 2015, Jan Hubicka wrote: > > > ... we initialize mode to be non-VOIDmode only if the field is not > > bitfield. I missed > > the flag while looking at the dump. Indeed the DECL_MODE if FIELD_DECL is > > SImode, > > but

Re: Do not use TYPE_CANONICAL in useless_type_conversion

On Oct 9, 2015, Jan Hubicka wrote: > ... we initialize mode to be non-VOIDmode only if the field is not bitfield. > I missed > the flag while looking at the dump. Indeed the DECL_MODE if FIELD_DECL is > SImode, > but it is ignored. > Hmm, it seems that for CALL_EXPR the

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> How about using in store_bit_field the same logic you added to > store_expr_with_bounds to get input MEMs to have a compatible mode? > This patch was regstrapped on i686-linux-gnu and x86_64-linux-gnu. Ok > to install? > > > support BLKmode inputs for store_bit_field > > From: Alexandre

Re: Do not use TYPE_CANONICAL in useless_type_conversion

On Oct 13, 2015, Eric Botcazou wrote: > Note that this is PR middle-end/67912. Thanks. I added this piece of information to the ChangeLog entry, and checked the patch in. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish

Re: Do not use TYPE_CANONICAL in useless_type_conversion

Jan Hubicka writes: > Does the patch in https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00902.html > help? No, it doesn't. #0 fancy_abort (file=0x43f1ce48 "../../gcc/expr.c", line=282, function=0x43f1ec38

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> I think a FIELD_DECL with VOIDmode is odd. As I said in my earlier message, the FIELD_DECL does *not* have VOIDmode. > And yes, the type of the COMPONENT_REF should be that of the FIELD_DECL (or > a variant type of it as we share FIELD_DECLs for record variants). But it is of course! Jan is

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> The type has BLKmode and size 32. DECL_SIZE of the FIELD_DECL is however 24 > (see it printed as Ada size). Yes, no wonder since it's a bitfield, i.e. DECL_BIT_FIELD is set. > The DECL_MODE of the FIELD_DECL is VOIDmode (not printed), while the > TYPE_MODE of type contained is BLKmode. No,

Re: Do not use TYPE_CANONICAL in useless_type_conversion

On Fri, 9 Oct 2015, Jan Hubicka wrote: > > > > Index: expr.c > > === > > --- expr.c (revision 228604) > > +++ expr.c (working copy) > > @@ -6703,7 +6704,7 @@ store_field (rtx target, HOST_WIDE_INT b > > emit_group_store

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> Jan Hubicka writes: > > > Does the patch in https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00902.html > > help? > > No, it doesn't. > > #0 fancy_abort (file=0x43f1ce48 "../../gcc/expr.c", line=282, > function=0x43f1ec38

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> > The type has BLKmode and size 32. DECL_SIZE of the FIELD_DECL is however 24 > > (see it printed as Ada size). > > Yes, no wonder since it's a bitfield, i.e. DECL_BIT_FIELD is set. > > > The DECL_MODE of the FIELD_DECL is VOIDmode (not printed), while the > > TYPE_MODE of type contained is

Re: Do not use TYPE_CANONICAL in useless_type_conversion

On Thu, 8 Oct 2015, Jan Hubicka wrote: > > > > && TREE_CODE (outer_type) == OFFSET_TYPE > > > > Ok with those changes. > > Thank you! I commited the patch. At a hike today it appeared to me that > for ipa-icf and other calling convetions checks we should not rely on >

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> Thank you! I commited the patch. It breaks the Ada build on x86-64 though: eric@polaris:~/build/gcc/native/gcc/ada/rts> /home/eric/build/gcc/native/./gcc/xgcc -B/home/eric/build/gcc/native/./gcc/ - B/home/eric/install/gcc/x86_64-suse-linux/bin/ - B/home/eric/install/gcc/x86_64-suse-linux/lib/

Re: Do not use TYPE_CANONICAL in useless_type_conversion

On Thu, 8 Oct 2015, Jan Hubicka wrote: > > > > && TREE_CODE (outer_type) == OFFSET_TYPE > > > > Ok with those changes. > > Thank you! I commited the patch. > At a hike today it appeared to me that for ipa-icf and other calling > convetions > checks we should not rely on

Re: Do not use TYPE_CANONICAL in useless_type_conversion

Eric Botcazou writes: >> Thank you! I commited the patch. > > It breaks the Ada build on x86-64 though: Also on ia64: /usr/local/gcc/test/Build/./prev-gcc/xgcc -B/usr/local/gcc/test/Build/./prev-gcc/ -B/usr/ia64-suse-linux/bin/ -B/usr/ia64-suse-linux/bin/

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> > Thank you! I commited the patch. > > It breaks the Ada build on x86-64 though: Hmm, I tested Ada on ppc64 only. I will look into that today. Honza > > eric@polaris:~/build/gcc/native/gcc/ada/rts> > /home/eric/build/gcc/native/./gcc/xgcc -B/home/eric/build/gcc/native/./gcc/ - >

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> > Heh, we need a calling convention checker in > gimple_builtin_call_types_compatible_p and friends! Yep, i will try to play with this. So far I did not managed to create a testcase that would expose a wrong code in ICF. > > Btw, with the TYPE_CANONICAL changes I wonder whether we can make

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> > Index: expr.c > === > --- expr.c(revision 228604) > +++ expr.c(working copy) > @@ -6703,7 +6704,7 @@ store_field (rtx target, HOST_WIDE_INT b > emit_group_store (temp_target, temp, TREE_TYPE (exp), size); >

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> Eric Botcazou writes: > > >> Thank you! I commited the patch. > > > > It breaks the Ada build on x86-64 though: > > Also on ia64: Sorry to hear that :( > > /usr/local/gcc/test/Build/./prev-gcc/xgcc > -B/usr/local/gcc/test/Build/./prev-gcc/ -B/usr/ia64-suse-linux/bin/

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> On Thu, 8 Oct 2015, Jan Hubicka wrote: > > > > > > > && TREE_CODE (outer_type) == OFFSET_TYPE > > > > > > Ok with those changes. > > > > Thank you! I commited the patch. > > At a hike today it appeared to me that for ipa-icf and other calling > > convetions > > checks we should not rely on

Re: Do not use TYPE_CANONICAL in useless_type_conversion

On Wed, 7 Oct 2015, Jan Hubicka wrote: > > > > > > The patch works for me but I'm not sure about the store_expr_with_bounds > > > change. Where does the actual copying take place? adjust_address_nv > > > just adjusts the mode ... > > > > Yep, the mode was supposed to happen in the later path

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> > > > The patch works for me but I'm not sure about the store_expr_with_bounds > > change. Where does the actual copying take place? adjust_address_nv > > just adjusts the mode ... > > Yep, the mode was supposed to happen in the later path where we emit block > moves, > but i missed an else

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> > && TREE_CODE (outer_type) == OFFSET_TYPE > > Ok with those changes. Thank you! I commited the patch. At a hike today it appeared to me that for ipa-icf and other calling convetions checks we should not rely on useless_type_conversion_p because there may be types that are compatible in

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> > The patch works for me but I'm not sure about the store_expr_with_bounds > change. Where does the actual copying take place? adjust_address_nv > just adjusts the mode ... Yep, the mode was supposed to happen in the later path where we emit block moves, but i missed an else there. I will

Re: Do not use TYPE_CANONICAL in useless_type_conversion

On Mon, 5 Oct 2015, Jan Hubicka wrote: > > >+ /* For aggregates compare only the size and mode. Accesses to fields > > >do have > > >+ a type information by themselves and thus we only care if we can i.e. > > >+ use the types in move operations. */ > > >else if (AGGREGATE_TYPE_P

Re: Do not use TYPE_CANONICAL in useless_type_conversion

+ /* For aggregates compare only the size and mode. Accesses to fields do have + a type information by themselves and thus we only care if we can i.e. + use the types in move operations. */ else if (AGGREGATE_TYPE_P (inner_type) && TREE_CODE (inner_type) == TREE_CODE

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> >+ /* For aggregates compare only the size and mode. Accesses to fields do > >have > >+ a type information by themselves and thus we only care if we can i.e. > >+ use the types in move operations. */ > >else if (AGGREGATE_TYPE_P (inner_type) > >&& TREE_CODE (inner_type)

RE: Do not use TYPE_CANONICAL in useless_type_conversion

Hi, On Fri, 2 Oct 2015 23:31:09, Eric Botcazou wrote: > > It's related to a known difficulty with alignment and inheritance, and other > languages are affected by variant of it, see e.g. PR c++/37798. > I doubt that this is still an issue with the current trunk. I tried the test case from the

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> I doubt that this is still an issue with the current trunk. > > I tried the test case from the pr37798 on x86_64, and now the object is > 8-aligned, but the object was only 4-byte aligned according to the comments > in the bugzilla at that time. Yes, it's already fixed with the 4.9.x compiler

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> There must be a reason why I allowed modes to differ there btw ;) Thinking about it, I guess reason is that incomplete types do not have resonable modes set, so requiring modes to match will prevent complete and incomplete types to match. Here is updated patch which uses the earlier mode check

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> I believe TYPE_ALIGN_OK should be "lowered" so that if you have a > handled-component chain with some intermediate TYPE_ALIGN_OK you > lower it to taking the address of that component and dereferencing > it (which is where the middle-end always trusts the alignment of > the type of the

Re: Do not use TYPE_CANONICAL in useless_type_conversion

Hi, actually I do not quite understand why we need a TYPE_ALIGN_OK flag that is only used in Ada. Somehow other languages seem to have no problem of that kind. You remember, when I removed the TYPE_ALIGN_OK handing (initially it wasn't clear to me that it's entire use is only to make Ada

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> On Fri, 2 Oct 2015, Jan Hubicka wrote: > > > > There must be a reason why I allowed modes to differ there btw ;) > > > > Thinking about it, I guess reason is that incomplete types do not have > > resonable modes set, so requiring modes to match will prevent complete > > and incomplete types to

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> > On Fri, 2 Oct 2015, Jan Hubicka wrote: > > > > > > There must be a reason why I allowed modes to differ there btw ;) > > > > > > Thinking about it, I guess reason is that incomplete types do not have > > > resonable modes set, so requiring modes to match will prevent complete > > > and

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> actually I do not quite understand why we need a TYPE_ALIGN_OK flag that is > only used in Ada. Somehow other languages seem to have no problem of that > kind. It's related to a known difficulty with alignment and inheritance, and other languages are affected by variant of it, see e.g. PR

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> > Index: expr.c > > === > > --- expr.c (revision 228267) > > +++ expr.c (working copy) > > @@ -5462,7 +5462,12 @@ store_expr_with_bounds (tree exp, rtx ta > > { > >if (GET_MODE (temp) != GET_MODE (target) && GET_MODE

Re: Do not use TYPE_CANONICAL in useless_type_conversion

Hi, so this is variant without the BLKmode subreg that passes testing on ppc64-linux. The case of parlallel and copy_blkmode_to_reg appears to be handled upstream in expand_assignment. Honza * expr.c (store_expr_with_bounds): Handle aggregate moves from BLKmode. *

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> Index: expr.c > === > --- expr.c(revision 228267) > +++ expr.c(working copy) > @@ -5462,7 +5462,12 @@ store_expr_with_bounds (tree exp, rtx ta > { >if (GET_MODE (temp) != GET_MODE (target) && GET_MODE (temp) !=

Re: Do not use TYPE_CANONICAL in useless_type_conversion

On Thu, 1 Oct 2015, Eric Botcazou wrote: > > Do we require that to match? I don't remember that we do. > > For scalar types (and arrays of scalars), the alignment is essentially > encoded > in the size/mode pair but that's not the case for non-array aggregate types, > so declaring a

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> Yep, I was thinking of alignment. I think we are safe here as we are safe > with any other memory access properties in the references. Those are not > supposed to be preserved by useless_type_conversions. Some explicit type casts need to be preserved on memory accesses, see the TYPE_ALIGN_OK

Re: Do not use TYPE_CANONICAL in useless_type_conversion

On Thu, 1 Oct 2015, Jan Hubicka wrote: > > > - /* For aggregates we rely on TYPE_CANONICAL exclusively and require > > > - explicit conversions for types involving to be structurally > > > - compared types. */ > > > + /* For aggregates compare only the size and mode. Accesses to

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> Yeah, though we don't have conversions of aggregates. We use the > predicate to tell whether an aggregate assignment is valid GIMPLE. > LHS and RHS alignment do not have to match AFAIK. So it doesn't control whether VIEW_CONVERT_EXPRs are preserved or not? -- Eric Botcazou

Re: Do not use TYPE_CANONICAL in useless_type_conversion

On Fri, 2 Oct 2015, Jan Hubicka wrote: > > There must be a reason why I allowed modes to differ there btw ;) > > Thinking about it, I guess reason is that incomplete types do not have > resonable modes set, so requiring modes to match will prevent complete > and incomplete types to match. Hmm.

Re: Do not use TYPE_CANONICAL in useless_type_conversion

On Fri, 2 Oct 2015, Eric Botcazou wrote: > > Yep, I was thinking of alignment. I think we are safe here as we are safe > > with any other memory access properties in the references. Those are not > > supposed to be preserved by useless_type_conversions. > > Some explicit type casts need to be

Re: Do not use TYPE_CANONICAL in useless_type_conversion

On Fri, 2 Oct 2015, Eric Botcazou wrote: > > Yeah, though we don't have conversions of aggregates. We use the > > predicate to tell whether an aggregate assignment is valid GIMPLE. > > LHS and RHS alignment do not have to match AFAIK. > > So it doesn't control whether VIEW_CONVERT_EXPRs are

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> After dropping the check I needed to solve two issues. First is that we need > a definition of useless conversions for aggregates. As discussed earlier I > made it to depend only on size. The basic idea is that only operations you > can do on gimple with those are moves and field accesses. Field

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> Do we require that to match? I don't remember that we do. For scalar types (and arrays of scalars), the alignment is essentially encoded in the size/mode pair but that's not the case for non-array aggregate types, so declaring a conversion that changes the alignment as useless seems weird.

Re: Do not use TYPE_CANONICAL in useless_type_conversion

On Thu, 1 Oct 2015, Eric Botcazou wrote: > > After dropping the check I needed to solve two issues. First is that we need > > a definition of useless conversions for aggregates. As discussed earlier I > > made it to depend only on size. The basic idea is that only operations you > > can do on

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> > - /* For aggregates we rely on TYPE_CANONICAL exclusively and require > > - explicit conversions for types involving to be structurally > > - compared types. */ > > + /* For aggregates compare only the size and mode. Accesses to fields do > > have > > + a type information by

Re: Do not use TYPE_CANONICAL in useless_type_conversion

> > Do we require that to match? I don't remember that we do. > > For scalar types (and arrays of scalars), the alignment is essentially > encoded > in the size/mode pair but that's not the case for non-array aggregate types, > so declaring a conversion that changes the alignment as useless

Re: Do not use TYPE_CANONICAL in useless_type_conversion

On Wed, 30 Sep 2015, Jan Hubicka wrote: > Hi, > this implements the idea we discussed at Cauldron to not use TYPE_CANONICAL > for > useless_type_conversion_p. The basic idea is that TYPE_CANONICAL is language > specific and should not be part of definition of the Gimple type system that >

Do not use TYPE_CANONICAL in useless_type_conversion

Hi, this implements the idea we discussed at Cauldron to not use TYPE_CANONICAL for useless_type_conversion_p. The basic idea is that TYPE_CANONICAL is language specific and should not be part of definition of the Gimple type system that should be quite agnostic of language.