> >
> > Are you sure? I thought we compute that up-front ... at least
> > we make sure we can_inline_edge_p all calls before even trying
> > to inline all calls - that looks somewhat redundant then if it
> > can happen that we give up anyway. Ah, so can_inline_edge_p has
> >
> > /* Check if c
> On Mon, 22 Feb 2016, Jakub Jelinek wrote:
>
> > On Mon, Feb 22, 2016 at 01:44:09PM +0100, Richard Biener wrote:
> > > --- 1079,1086
> > > || !dominated_by_p (CDI_DOMINATORS,
> > > loop->latch, gimple_bb (stmt)))
> > > return;
> > > +
>
> Ok, so maybe a better question to symtab would be if there is an
> actual definition for what __builtin_FOO will call. Not really
> whether that definition is cfun. Of course all the fortify
> always-inline wrappers should not count as such (just in case
> the symtab code is confused about t
Hi,
while looking into PR69589 I noticed that types are not merged when pragma
visibility does not match. This is because C++ FE stores visibility into
TYPE_DECL
that is used by FE only. This patch clears the flag in free_lang_data.
Bootstrapped/regtested x86_64-linux and tested it makes no diff
Hi,
while looking into the PR testcase I noticed that we detect wrong duplicate
types. This is because we compute DECL_ASSEMBLER_NAME of a type variant which
is not necessary.
Bootstrapped/regested x86_64-linux and I checked dumps of xalancbmk to verify
that nothing changes in ODR type merging exc
> On 11/26/13 13:20, Jakub Jelinek wrote:
> >Hi!
> >
> >As the testcase in the patch shows, if exact memcpy or memset count
> >is unknown, but max_size is smaller than epilogue_size_needed,
> >ix86_expand_set_or_movmem can ICE.
> >
> >The following patch fixes that, bootstrapped/regtested on x86_64
> On 11/27/13 10:30, Yvan Roux wrote:
> >>Please include either the patch you are pinging or at the least a link to it
> >>in the archives.
> >
> >Ok, sorry for that, here is the patch and Changelog
> >
> >Yvan
> >
> >
> >2013-11-17 Yvan Roux
> >
> > * config/arm/arm.md (store_minmaxsi):
-partition again?
Honza
>
> Martin
>
> On 19 November 2013 23:18, Teresa Johnson wrote:
> > On Tue, Nov 19, 2013 at 9:40 AM, Jeff Law wrote:
> >> On 11/19/13 10:24, Teresa Johnson wrote:
> >>>
> >>> On Tue, Nov 19, 2013 at 7:44 AM, Jan Hubicka w
> > + Functions are no longer pointlessly renamed.
>
> Readers may struggle a bit with this. What does it refer to?
We previously renamed every static function foo into foo.1234
(just as a precaution because other compilation unit may have also function
foo).
This confuses many thins, so n
> There is a comment:
>
>FIXME: the flags is incorrectly enabled for amdfam10, Bulldozer,
>Bobcat and Generic. This is because disabling it causes large
>regression on mgrid due to IRA limitation leading to unecessary
>use of the frame pointer in 32bit mode. */
> DEF_TUNE (X86_TU
Hubicka j...@suse.cz
+i386 port Jan Hubicka hubi...@ucw.cz
i386 port Uros Bizjak ubiz...@gmail.com
ia64 port Jim Wilson wil...@tuliptree.org
ia64 port Steve Ellceysell...@mips.com
@@ -112,7
> Here is the updated patch. Tested on Linux/x86-64. It
> fixed git. OK to install?
>
> Thanks.
>
> --
> H.J.
> ---
> gcc/
>
> 2013-12-03 H.J. Lu
>
> PR target/59363
> * config/i386/i386.c (emit_memset): Adjust destination address
> after gen_strset.
> (expand_setmem_epi
> Hello,
>there are dumps for Inkscape, it looks very well. There are few of
> functions that look like this (wpa cgraph):
>
> _ZL13resync_activeP19_EgeSelectOneActionii/2604322 (resync_active)
> @0x7f84af42cea0
> Type: function definition analyzed
> Visibility: prevailing_def_ironly
> R
> Can you, please, send me the -flto systemtaps for gimp and/or inkscape so we
> can decide
> on the patch? We should enable it earlier in stage3 rather than later.
I see, the PDF was included within the tar file. Was this with
-freorder-blocks-and-partition? If so, the patch is OK.
I still thi
t; If you look at the graph line, it looks really well.
>
> I will prepare patch for mailing list as a phase 2.
>
> Martin
>
> On 5 December 2013 14:38, Jan Hubicka wrote:
> >> Can you, please, send me the -flto systemtaps for gimp and/or inkscape so
> >> w
> On Thu, 21 Nov 2013, Jan Hubicka wrote:
>
> > >
> > > Why do you need an additional -fparallelism? Wouldn't
> > > -fwpa=... be a better match, matching -flto=...? As we already
> > > pass down a -fwpa option to WPA this would make things easier
> Hi, all
>
> This is the new patch for gcov-tool (previously profile-tool).
>
> Honza: can you comment on the new merge interface? David posted some
> comments in an earlier email and we want to know what's your opinion.
>
> Test patch has been tested with boostrap, regresssion,
> profiledboots
> This all started with Stuart Hastings' original decloning patch way
> back in 2002:
> http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00354.html
> Bill Maddox tried to revive it in 2007:
> http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01147.html
>
> I'm embarrassed that it has taken so long to g
> > * gimple-fold.c (can_refer_decl_in_current_unit_p): Check
> > references to comdat-local symbols.
Also i think this change needs more work. FROM_DECL is not the function you
are going to get the refernece, it is variable whose constructor the value was
take from.
I thi
> > diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
> > index fbb63da..aa49bfe 100644
> > --- a/gcc/ipa-inline.c
> > +++ b/gcc/ipa-inline.c
> > @@ -230,6 +230,25 @@ report_inline_failed_reason (struct cgraph_edge *e)
> > }
> > }
> >
> > +/* True iff NODE calls another function which is loc
> Hi,
>
>
> ChangeLog
>
> 2013-12-06 Kai Tietz
>
> PR target/56807
> * config/i386/i386.c (ix86_expand_prologue):
>
> Tested for i686-w64-mingw32, x86_64-unknown-linux-gnu. Ok for apply?
So the code in question does spilling relative to stack pointer before function
call and relat
> On Tue, Dec 10, 2013 at 12:48:20PM +0100, Jan Hubicka wrote:
> > > Hi,
> > >
> > >
> > > ChangeLog
> > >
> > > 2013-12-06 Kai Tietz
> > >
> > > PR target/56807
> > > * config/i386/i386.c (ix86_
> On 12/10/2013 04:48 AM, Jan Hubicka wrote:
> >The case where I played with local comdats was the following.
> >I made cgraph_body_availability to get context argument (i.e. instead of
> >saying
> >if something is available in current unit, it was saying if it is avail
> On 12/11/2013 08:55 AM, Jan Hubicka wrote:
> >>>>+ /* Don't clone decls local to a comdat group. */
> >>>>+ if (comdat_local_p (node))
> >>>>+return false;
> >>>
> >>>Why? It seems this should work if the clone b
> On 12/11/2013 10:11 AM, Jason Merrill wrote:
> >So, it's probably possible to make it work to clone the comdat local
> >function into another comdat local function, but it's not useful, and
> >it's easier to just prevent it.
>
> Well, not that much easier actually. I'm attaching both a delta
>
Hi,
while thinking of the details on how to handle comdat locals through
ipa-cp/inliner/folding
I wonder, if we won't end up with better code going the oposite way.
We can declare those functions static first and then have post-inliner IPA pass
that will
travel the callgraph and mark all static f
> On 12/11/2013 12:45 PM, Jan Hubicka wrote:
> >I wonder, if we won't end up with better code going the oposite way.
> >We can declare those functions static first and then have post-inliner IPA
> >pass that will
> >travel the callgraph and mark all sta
> On 12/11/2013 12:14 PM, Jan Hubicka wrote:
> >>Is ipa_passes the right place to initialize calls_comdat_local?
> >
> >The flag is probably needed in both early inliner and IPA inliner. A
> >conservative
> >place to initialize it would be in inline_analyze
Hi,
> diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
> index f368cab..3576f7d 100644
> --- a/gcc/c-family/c-opts.c
> +++ b/gcc/c-family/c-opts.c
> @@ -899,6 +899,10 @@ c_common_post_options (const char **pfilename)
>if (warn_implicit_function_declaration == -1)
> warn_implicit_
summaries (so the number
of runs did not match). I fixed it by
2013-11-18 Jan Hubicka
* libgcov-driver.c (run_accounted): Make global level static.
(gcov_exit_merge_summary): Silence warning; do not clear
run_accounted here.
(gcov_exit): Clear i
> On Wed, Dec 11, 2013 at 1:21 AM, Martin Liška wrote:
> > Hello,
> >I prepared a collection of systemtap graphs for GIMP.
> >
> > 1) just my profile-based function reordering: 550 pages
> > 2) just -freorder-blocks-and-partitions: 646 pages
> > 3) just -fno-reorder-blocks-and-partitions: 638
> On 12/12/2013 03:08 PM, Jan Hubicka wrote:
> >So only reason why this is optimize_size only is the fact that we can't rely
> >on inliner
> >to fix up the wrappers?
>
> I was just being conservative. In fact, the inliner seems to handle
> small [cd]tors we
> On 2013.12.06 at 10:43 +0100, Richard Biener wrote:
> > On Fri, 6 Dec 2013, Jan Hubicka wrote:
> >
> > > > On Thu, 21 Nov 2013, Jan Hubicka wrote:
> > > >
> > > > > >
> > > > > > Why do you need an additional -fpar
> On 12/13/2013 05:58 AM, Jan Hubicka wrote:
> >>+ if (callee->calls_comdat_local)
> >>+to->calls_comdat_local = true;
> >>+ else if (to->calls_comdat_local && symtab_comdat_local_p (callee))
> >>+{
> >>+ st
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
Hi,
this patch fixes first part of PR58477. Here we miss IPA devirtualization
opurtunity but
produce speculative call. Later during inlining, the standard folders produce
direct call
and we ICE after cgraph_clone_edge messes up the speculative call info.
This patch makes cgraph_clone_edge to d
Hi,
sorry for taking time to return back to this.
> Pre-remark:
>
> I had hoped that something like the following patch would work.
> However, it will lead to a bunch of run-time segfaults in the test
> suite - but the original dump seems to be fine and I also fail to
> spot the problem when looki
> Hi Honza,
>
> Jan Hubicka wrote:
> >But if you have something like
> >
> >a=__builtin_expect (b?1:0,0)
> >
> >and you produce
> >
> >a=b?predict_expr not_taken, 0,0
> >...
> >if (a)
> > unlikely path
> >
> >W
Hi,
the problem here is ipa-prop trying to analyze indirect call that has been
already turned to direct. While early opts should optimize this call (and
in fact I have approved patch to do so I forgot to apply), we should
not ICE in this case.
Fixed thus,
bootstrapped/regtested x86_64-linux, will
> Jan Hubicka wrote:
> >Yep, they should not roduce incorrect code. Isn't the problem
> >that you expect the whole expression to have value and predit_expr
> >"reutrns" nothing?
> >Can you check what lands into gimple?
>
> That could well be
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 93e857df..d5a0ac8 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,14 @@
> +2013-12-15 Martin Liska
> + Jan Hubicka
> +
> + * cgraphunit.c (node_cmp): New function.
> + (e
> Hello,
>there's updated version of the patch.
>
> Tested on x86_64 with enable bootstrap.
>
> Martin
>
> On 16 December 2013 00:21, Jan Hubicka wrote:
> >> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> >> index 93e857df..d5a0ac8 100644
&g
)
+++ ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2013-12-14 Jan Hubicka
+
+ PR ipa/59473
+ * ipa-devirt.c (get_class_context): Do not ICE when type is found
+ at wrong offset.
+
2013-12-16 Jakub Jelinek
PR libgomp/58756
Index: ipa-devirt.c
)
@@ -1,3 +1,10 @@
+2013-12-14 Jan Hubicka
+ Markus Trippelsdorf
+
+ PR ipa/59265
+ * ipa-profile.c (ipa_profile_generate_summary): Do not ICE when
+ call is already devirtualized.
+
2013-12-16 Jakub Jelinek
* Makefile.in (version.o): Restore
> 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, thank
> On 12/13/13 12:42, Aldy Hernandez wrote:
> >I'm fixing something completely unrelated, and noticed this...
> >
> >Perhaps I'm missing something, but why do we need a gate when it always
> >returns true? Now that we have this `pass_data' business, we can set
> >has_gate to false.
> >
> >I also fi
ummary
> > gcov_seek
> >
> > Should they all, plus gcov_rewrite, be moved to libgcov-driver.c?
> >
> > Teresa
> >
> >>
> >>
> >> David
> >>
> >> On Thu, Dec 12, 2013 at 12:11 PM, Teresa Johnson
> >> wrote:
> >>> On Wed,
Hi,
I forgot the following change in my tree. It fixes type consistency sanity
check in get_polymorphic_call_info. With the change to gimple-fold it is
now needed to devrirtualize devirt2.C. (previously the bug went latent since
the old code handled the testcase)
I am re-testing x86_64-linux and
> On Tue, Dec 17, 2013 at 3:04 AM, Jan Hubicka wrote:
> > Hi,
> > I forgot the following change in my tree. It fixes type consistency sanity
> > check in get_polymorphic_call_info. With the change to gimple-fold it is
> > now needed to devrirtualize devirt2.C. (pre
Hi,
PR 35545 has trivial testcase of feedback directed devirtualization:
int main()
{
int i;
A* ap = 0;
for (i = 0; i < 1; i++)
{
if (i%7==0)
ap = new A();
else
ap = new B();
ap->foo();
Here we should devirtualize since B's foo is dominating targe
Hi,
this patch contines on tract of making us to handle OBJ_TYPE_REF in expressions
more gracefully. The change in gimple_fold_stmt_to_constant_1 makes
it to skip the wrapper, so valuelize functions of passes never see it,
and in addition OBJ_TYPE_REF is stripped once argument becomes constant.
I
> On 12/17/13 23:53, Tobias Burnus wrote:
> >Am 17.12.2013 21:56, schrieb Jeff Law:
> >>>* tree-vrp.c (extract_range_from_unary_expr_1): Add OBJ_TYPE_REF
> >>s/Add/Handle. Please add the PR marker as well.
> >>
> >>OK with that trivial nit.
> >
> >And the proper PR. I don't think that INVALID
> > 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 Tue, Dec 17, 2013 at 7:48 AM, Teresa Johnson wrote:
> > On Mon, Dec 16, 2013 at 2:48 PM, Xinliang David Li
> > wrote:
> >> Ok -- gcov_write_counter and gcov_write_tag_length are qualified as
> >> low level primitives for basic gcov format and probably should be kept
> >> in gcov-io.c.
> >>
> commit be1b04c77a420288e29c48c07e68c3ec87dd5b24
> Author: Jason Merrill
> Date: Thu Jan 12 14:04:42 2012 -0500
>
> PR c++/41090
> Add -fdeclone-ctor-dtor.
> gcc/cp/
> * optimize.c (can_alias_cdtor, populate_clone_array): Split out
> from maybe_clone_body.
> (
> Hi!
>
> Honza recently changed the i?86 backend, so that it often doesn't
> do -maccumulate-outgoing-args by default on x86_64.
> Unfortunately, on some of the here included testcases this regressed
> quite a bit the generated code. As AVX vectors are used, the dynamic
Yep, the accidental chan
> Hi Honza,
>
> We have combined generic32 and generic64 into generic. There is no need
> to check "generic" anymore. Also we shouldn't change -mtune=i686 into
> -mtune=generic. OK to install?
The i686->generic change was intended to get generic optimized code
for i686-linux configuration rath
> On Thu, Dec 26, 2013 at 4:38 AM, Jan Hubicka wrote:
> >> Hi Honza,
> >>
> >> We have combined generic32 and generic64 into generic. There is no need
> >> to check "generic" anymore. Also we shouldn't change -mtune=i686 into
> >> -
>
> Yes. Also affecting other statements isn't allowed.
>
> >One would need to also unlink vdefs and release the vdef SSA_NAME, and
> >not
> >sure if fold_stmt_inplace callers would be even prepared for the stmt
> >to
> >become noreturn, and no longer throwing, etc.
>
> That I think they have t
Hi,
this is C version
static int (*p) (int a) = (int (*)(int))__builtin_unreachable;
main()
{
return p(1);
}
Here we get in CCP:
Folding statement: return _4;
Not folded
Folding statement: _4 = p.0_2 (1);
Folded into: _4 = __builtin_unreachable (1);
Removing dead stmt p.0_2 = __builtin_unreacha
> On Mon, Dec 30, 2013 at 10:14:16PM +0100, Jan Hubicka wrote:
> > this is C version
> > static int (*p) (int a) = (int (*)(int))__builtin_unreachable;
> > main()
> > {
> > return p(1);
> > }
>
> Well, that testcase is invalid, as you are calling
> >I think so, after all don't we set noreturn attribute automatically
> >even if it is missing when IPA can prove the function never returns?
> >If we fold_stmt after that, the above testcase even without explicit
> >noreturn attribute would need cfg cleanup.
> >
> >Perhaps gimple_fold_call should
Hi,
this patch fixes ICE seen with -mno-accumulate-outgoing-args bootstrap building
go runtime.
The ICE is in dwarf2cfi.c while checking that on all paths into given basic
block stack
frames are same. It goes away either with disabling crossjumping or sched2 but
the problem
IMO really originate
Hi,
currently we have somewhat non-sential setting for accumulate-ougoing-args.
It is disabled for Intel chips because recent chips do have stack engines making
push/pop instructions cheap, it is however enabled for AMD chips and Generic.
Originally accumulation was disabled since push/pop instruc
Hi,
While looking for -Winline messages I noticed that sched-int.h has self
recursive
function declared inline. The recursion is tail recursion but we fail to
recognize
it as such. The problem ist hat there is a local variable link whose address
is passed to function &DEPS_LIST_FIRST (list) and
Hi,
those functions are not inlined since they are too large anyway.
I do not think it is disaster. get_attr_length_1 takes a callback
that may make it more interesting inlining candidate than others,
perhaps.
Bootstrapped/regtested x86_64-linux, OK?
Honza
* gengtype-state.c (fatal_readi
> > Frankly speaking, I do not understand, what's wrong here.
> > IMHO, this change is pretty mechanical: we just extend maximal aligment
> > available. Because of 512-bit data types we now extend maximal aligment to
> > 512 bits.
>
> Nothing wrong per se, but...
>
> > I suspect that an issue is
> > x86-64 ABI has clause about aligning static vars to 128bit boundary at a
> > given size. This was introduced to aid compiler to generate aligned
> > vector store/load even if the object may bind to other object file.
> > This is set to stone and can not be changed for AVX/SSE.
>
> Yes, but th
> 2014-01-03 Rong Xu
>
> * gcc/gcov-io.c (gcov_var): Move from gcov-io.h.
> (gcov_position): Ditto.
> (gcov_is_error): Ditto.
> (gcov_rewrite): Ditto.
> * gcc/gcov-io.h: Refactor. Move gcov_var to gcov-io.h, and libgcov
> only part to libgcc/libgc
> On 12/22/2013 01:27 PM, Jan Hubicka wrote:
> >
> >I believe when the code was created by moving it from elsehwre, the
> >copyright should say
> >original date of gcov-io.h.
> >>+
> >>+#include "tconfig.h"
> >>+#include "tsys
> On 01/02/14 10:21, Jan Hubicka wrote:
> >Hi,
> >While looking for -Winline messages I noticed that sched-int.h has self
> >recursive
> >function declared inline. The recursion is tail recursion but we fail to
> >recognize
> >it as such. The problem ist h
>
> Actually, I tried changing these two, but gcc_checking_assert is
> undefined in libgcov.a. Ok to commit without this change?
OK.
incrementally can you please define gcov_nonruntime_assert that will wind into
gcc_assert for code within gcc/coverage tools and into nothing for libgcov
runtime an
>
> I don't understand why static variables can cause any safety issue in
> multi-thread programs.
> For any process, gcov_dump will be called only once and there will be
> one instance of globals.
(v)fork, failing exec and other cases can lead to gcov_flush being called
several times and that c
> As suggested by Honza, avoid bloating libgcov from gcc_assert by using
> a new macro gcov_nonruntime_assert in gcov-io.c that is only mapped to
> gcc_assert when not in libgcov.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu. Ok for trunk?
>
> Thanks,
> Teresa
>
> 2014-01-09 Teresa J
Hi,
this patch fixes IPA-devirt testcase that gave me bad sleep for months. The
problem turned out to be combination of three issues (that greatly confused
me). This patch fixes first two. Here representation of BINFOs of multiple
inheritnace actually differs from my mental modem. For diamond sha
Hi,
this patch fixes checking ICE in the attached testcase that happens because we
end up
devirtualizing into a function that is not withing possible polymorphic call
target.
The defauled analysis is in the PR and also in comment bellow. The basic
problem
is that we build type inheritance tree
> > What has changed between then and now? Also, do we not use
> > estimates/heuristics when not using a profile?
>
> Nothing has changed - splitting effectively never kicked in without a
> profile. Honza and I had discussed the idea that static profile
> heuristics could eventually be used to dis
> On 09/29/2015 12:41 AM, Senthil Kumar Selvaraj wrote:
> >On Mon, Sep 28, 2015 at 01:38:18PM -0600, Jeff Law wrote:
> >>On 09/28/2015 02:15 AM, Senthil Kumar Selvaraj wrote:
> >>>Hi,
> >>>
> >>> The below patch skips gcc.dg/addr_equal-1.c if the target keeps null
> >>> pointer checks.
> >>>
>
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.
useless_type_convers
> > 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 se
> > - /* 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 th
> 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
> 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 com
it still bootstraps and tests
> fine on an x86_64-linux. OK for trunk?
>
> Thanks,
>
> Martin
>
>
> 2015-02-25 Martin Jambor
> Jan Hubicka
>
> * ipa-cp.c (ipcp_alignment_lattice): New type.
> (ipcp_param_lattices): Use the above to
> > 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 requi
> > 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 (
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.
* gimple-
> On Thu, 1 Oct 2015, Richard Biener wrote:
>
> >
> > The following avoids quadraticness in the loop depth by only considering
> > loop header defs as IVs for the analysis of the loop_stride predicate.
> > This will miss cases like
> >
> > foo (int inv)
> > {
> > for (i = inv; i < n; ++i)
> >
> >+ /* 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) ==
Hi,
While looking for uses of useless_type_conversion on non-gimple register types
I run across few that seem to be completely unnecesary and I would like to get
rid of them in hope to get rid of code comparing functions/method type and
possibly more.
usless_type_conversion is about operations on
>
> 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 u
Hi,
I see, OEP_CONSTANT_ADDRESS_OF is set in:
return operand_equal_p (TREE_OPERAND (arg0, 0), TREE_OPERAND (arg1, 0),
TREE_CONSTANT (arg0) && TREE_CONSTANT (arg1)
? OEP_CONSTANT_ADDRESS_OF | OEP_ADDRESS_OF : 0);
so it is not addi
Hi,
adding some extra sanity checks to operand_equal_p made me to notice that uses
of operand_equal_p in mem attrs really care about addresses only. The
expression
is tree of the original memory acces MEM RTX was created from and thus the
comparsions should be done with OEP_ADDRESS_OF.
Bootstrap
> > I also disabled type matching done by operand_equal_p and cleaned up the
> > conditional of MEM_REF into multiple ones - for example it was passing
> > OEP_ADDRESS_OF when comparing TYPE_SIZE which is quite a nonsense.
> >
> > I wonder what to do about OPE_CONSTANT_ADDRESS_OF. This flag does
Hi,
this patch fixes use of operand_equal_p in fold_comparison where
we compare two addresses for equivalence and in
fold_addr_of_array_ref_difference.
Bootstrapped/regtested x86_64-linux, OK?
Honza
* fold-const.c (fold_comparison, fold_addr_of_array_ref_difference):
Pass OEP_AD
> >
> > 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
>
> Did you audit all callers of mem_attrs_eq_p to see if they really
> only care about that? After all MEM_EXPR, via access paths, encode
> type-based alias info and thus replacing one with the other (cse.c use
> or ifcvt.c use) is only valid if that doesn't break dependences.
Hmm, expr is used
> > This patch broke Solaris bootstrap in stage 1 with g++ 4.9:
> >
> > /vol/gcc/src/hg/trunk/solaris/gcc/ipa-cp.c: In member function 'bool
> > ipcp_alignment_lattice::meet_with_1(unsigned int, unsigned int)':
> > /vol/gcc/src/hg/trunk/solaris/gcc/ipa-cp.c:855:56: error: call of
> > overloaded
Hello,
here is updated version of the patch, this time without need to modify
useless_type_conversion. Just to recall the issue, Fortran C interoperability
requires size_t to interoperate with signed version produced by Fortran FE.
Unlike the existing logic in aliasing that makes signed and unsign
>
> && 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 gimple
901 - 1000 of 5417 matches
Mail list logo
