Re: [PATCH] Sink clobbers if EH block contains just clobbers (PR tree-optimization/51117)

2011-12-12 Thread Michael Matz
Hi, On Mon, 12 Dec 2011, Jakub Jelinek wrote: Ok. So, I'm happy with your changes and rth already acked the tree-eh.c side, so can we just get an ack on these cfgexpand.c changes? Thanks. Hmpf, I would have simply committed without a re-approval, but if you think it's necessary I'll wait.

Re: [PATCH] Remove dead labels to increase superblock scope

2011-12-06 Thread Michael Matz
Hi, On Tue, 6 Dec 2011, Tom de Vries wrote: what should be the 'next' returned by delete_insn? There are exactly two calls of delete_insn that take the return value. One (delete_insn_and_edges) just uses it to return it itself (and there are no calls to delete_insn_and_edges that use the

Re: [PATCH] Fix PR middle-end/39976, 200.sixtrack degradation

2011-12-05 Thread Michael Matz
Hi, On Fri, 2 Dec 2011, Jeff Law wrote: So while continuing to have the phis in the available expression table is not useful beyond the current block, the equivalency created when a redundant PHI is encountered is useful to keep. That's why I said to only clear the avail_exprs stack/vect

Re: [PATCH] Remove dead labels to increase superblock scope

2011-12-05 Thread Michael Matz
Hi, On Sun, 4 Dec 2011, Eric Botcazou wrote: I'm just a bit worried about the name delete_label. delete_insn (label) should always do the right thing for a pure deletion; the point of the new routine is that it also moves instructions. It only fixes things up though, so that the RTL

Re: [PATCH] Fix PR middle-end/39976, 200.sixtrack degradation

2011-12-05 Thread Michael Matz
Hi, On Fri, 2 Dec 2011, William J. Schmidt wrote: on top of your current version. That ought to remove the added PHI expressions (and only them) from the hash table but retain the information of equality in the const_or_copies_stack. Checking the BB wouldn't be required then.

Re: [PATCH] Improve debug info if tree DCE removes stores (PR debug/50317)

2011-12-02 Thread Michael Matz
Hi, On Fri, 2 Dec 2011, Richard Guenther wrote: Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2011-12-01 Jakub Jelinek ja...@redhat.com PR debug/50317 * tree-ssa-dce.c (remove_dead_stmt): Add a debug stmt when removing as unnecessary a store

Re: [PATCH] Fix PR middle-end/39976, 200.sixtrack degradation

2011-12-02 Thread Michael Matz
Hi, On Fri, 2 Dec 2011, William J. Schmidt wrote: - tree def = gimple_get_lhs (stmt); + /* If this is a PHI, we only want to consider it if all of its + arguments are SSA names (which are known to be defined in a + single place). This avoids errors when dealing with

Re: [PATCH] Fix PR middle-end/39976, 200.sixtrack degradation

2011-12-02 Thread Michael Matz
Hi, On Fri, 2 Dec 2011, William J. Schmidt wrote: It seems like a fair amount of rip-up to avoid keeping the PHI state around between blocks, so I just check to ensure the PHI definitions occur in the same block before recording their equivalence. Then you should at least mix the BB

Re: [PATCH] Fix predcom ICE introduced by var clobber changes (PR tree-optimization/51246, take 2)

2011-12-01 Thread Michael Matz
Hi, On Thu, 1 Dec 2011, Richard Guenther wrote: As the default defs are already automatically handled by all our ssa infrastructure (including warning and propagation machinery) I think it would be best to generate such one instead of a clobber for the RHS. So like this? I

Re: [PATCH] Remove dead labels to increase superblock scope

2011-11-25 Thread Michael Matz
Hi, On Fri, 25 Nov 2011, Tom de Vries wrote: Note that you actually can remove labels also if they are !can_delete_label_p, if you use delete_insn (which you do). It will replace such undeletable labels by a DELETED_LABEL note. I tried that as well but ran into these errors in

Re: [PATCH] Fix predcom ICE introduced by var clobber changes (PR tree-optimization/51246)

2011-11-24 Thread Michael Matz
Hi, On Thu, 24 Nov 2011, Jakub Jelinek wrote: When stmt is mem = {v} {CLOBBER};, then lhs is neither SSA_NAME, but it doesn't satisfy gimple_assign_copy_p either. With this patch it will set the new_tree also to the clobber, making it clear that the next iteration uses unitialized variable.

Re: [PATCH] Fix predcom ICE introduced by var clobber changes (PR tree-optimization/51246, take 2)

2011-11-24 Thread Michael Matz
Hi, On Thu, 24 Nov 2011, Jakub Jelinek wrote: On Thu, Nov 24, 2011 at 05:28:00PM +0100, Michael Matz wrote: As the default defs are already automatically handled by all our ssa infrastructure (including warning and propagation machinery) I think it would be best to generate such one

Re: building trunk fails due to C++

2011-11-23 Thread Michael Matz
Hi, On Tue, 22 Nov 2011, Gary Funck wrote: Thanks for the tip. Typically, we don't build with --enable-checking=all, however ... We build with --enable-checking=all when we're testing major changes, moving GUPC to a new target architecture, etc. In the past, it may have been slower,

Re: Support enforcing use of libgcc_s even with LINK_EH_SPEC

2011-11-22 Thread Michael Matz
Hi, On Mon, 21 Nov 2011, Jakub Jelinek wrote: On Mon, Nov 21, 2011 at 05:40:26PM +0100, Rainer Orth wrote: 2011-11-20 Rainer Orth r...@cebitec.uni-bielefeld.de * gcc.c (init_gcc_specs) [USE_SHARED_LIBGCC_FOR_EH]: Always use libgcc_s. * config/sol2.h [USE_GLD]

[obvious] Fix PR51264

2011-11-22 Thread Michael Matz
Hi, there's a superfluous break in a switch in tree.c, which together with the object clobbers confuses our warning machinery at -O0, leading to a bootstrap fail for Tom. As we have testcases for that already in PR20681 there's no need in GCCs source base itself to contain something like

Re: building trunk fails due to C++

2011-11-22 Thread Michael Matz
Hi, On Tue, 22 Nov 2011, Gary Funck wrote: It gots much worse, with --enable-checking=all in combination with --enable-build-poststage1-with-cxx (the default, if c++ is built, and --enable-bootstrap is asserted). In fact, a build started last night on fast server hardware has yet to

Re: [patch, ia64, libgcc] Patch to fix libunwind build on IA64

2011-11-21 Thread Michael Matz
Hi, On Fri, 18 Nov 2011, Steve Ellcey wrote: Oh, so you don't even need -fasynchronous-unwind-tables? Even better then :) Didn't seem to. Do you know of any special tests I should check and/or run. No. I didn't see any problems in the GCC test suite after the bootstrap. Should

Fix PR51125 (was: death@scope broke TM tests)

2011-11-21 Thread Michael Matz
Hi, On Fri, 18 Nov 2011, Aldy Hernandez wrote: I just CC'ed you on a bug that I believe was caused by your patch. I forgot to CC you on the bug before I wrote the comment on it. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51125#c4 Perhaps you can take a look? The attached patch fixes

Re: [PATCH] Remove dead labels to increase superblock scope

2011-11-21 Thread Michael Matz
Hi, On Sat, 19 Nov 2011, Tom de Vries wrote: On 11/18/2011 10:29 PM, Eric Botcazou wrote: For the test-case of PR50764, a dead label is introduced by fixup_reorder_chain in cfg_layout_finalize, called from pass_reorder_blocks. I presume that there is no reasonable way of preventing

Re: [libitm, build] Support sun symbol versioning

2011-11-21 Thread Michael Matz
Hi, On Mon, 21 Nov 2011, Richard Henderson wrote: On 11/21/2011 06:06 AM, Rainer Orth wrote: * libitm.so wasn't versioned even with gld, since libitm_la_LDFLAGS wasn't passed when linking it. foo_LDFLAGS is supposed to be one of those auto variables that gets used when linking foo.

Re: Mark objects death at end of scope

2011-11-11 Thread Michael Matz
Hi, On Thu, 10 Nov 2011, Steve Ellcey wrote: This patch (r181172) has broken my bootstrap of IA64 Linux and I am trying to figure out what to do about it. The failure happens while building libunwind (I did not configure with --with-system-libunwind):

Re: Mark objects death@end of scope

2011-11-11 Thread Michael Matz
Hi, On Fri, 11 Nov 2011, Ulrich Weigand wrote: One reason why this happens is that the unwind*.c files are specifically built with -fexception. I think this is for the benefit of the DWARF unwinder, to ensure CFI records are available for those routines. Except for the routines that start

Re: increase call_saved_regs[] in caller-save.c

2011-11-07 Thread Michael Matz
Hi, On Sun, 6 Nov 2011, Jeff Law wrote: On Fri, 2011-11-04 at 12:25 -0600, Jeff Law wrote: The only way I can think of to have two pseudos assigned the same hard reg at the same point in the insn stream is if the two pseudos are known to have the same value. Having the same value is

Re: Mark objects death at end of scope

2011-11-07 Thread Michael Matz
Hi, On Thu, 3 Nov 2011, Richard Guenther wrote: Otherwise the patch looks ok, but given the Ada issue let's wait until that is sorted out in some way. That also gives others the chance to comment on the patch. So, this is what I came up with. As discussed I didn't do the uintptr_t case

Re: Patch ping

2011-11-04 Thread Michael Matz
Hi, On Fri, 4 Nov 2011, Richard Guenther wrote: With the approach the incremental patch does I just walk what split_constant_offset during DR walks and peel off loop invariants until I have something that should be used as the vectorized index. It looks like split_constant_offset

Re: [patch] 9/n: trans-mem: compiler ChangeLog entries

2011-11-04 Thread Michael Matz
Hi, On Thu, 3 Nov 2011, Aldy Hernandez wrote: +2010-05-28 Aldy Hernandez al...@redhat.com + + * target-def.h (TARGET_VECTORIZE_BUILTIN_TM_LOAD): Define. + (TARGET_VECTORIZE_BUILTIN_TM_STORE): Same. + (TARGET_VECTORIZE): Add TM callbacks. This actually meanwhile is in

Re: [patch] 15/n: trans-mem: compiler C++ changes

2011-11-04 Thread Michael Matz
Hi, On Thu, 3 Nov 2011, Aldy Hernandez wrote: +++ gcc/cp/parser.c (.../branches/transactional-memory) (revision 180773) @@ -172,6 +172,10 @@ typedef enum required_token { RT_JUMP, /* jump-statement */ RT_CLASS_KEY, /* class-key */ RT_CLASS_TYPENAME_TEMPLATE /* class,

Re: [patch] 14/n: trans-mem: compiler documentation

2011-11-04 Thread Michael Matz
Hi, On Thu, 3 Nov 2011, Aldy Hernandez wrote: Index: gcc/doc/tm.texi === --- gcc/doc/tm.texi (.../trunk) (revision 180744) +++ gcc/doc/tm.texi (.../branches/transactional-memory) (revision 180773) @@ -5758,6

Re: [patch] 19/n: trans-mem: compiler tree/gimple stuff

2011-11-04 Thread Michael Matz
Hi, On Thu, 3 Nov 2011, Aldy Hernandez wrote: +/* GIMPLE_EH_ELSE N_BODY, E_BODY must be the sole contents of + a GIMPLE_TRY_FINALLY node. For all normal exits from the try block, + we N_BODY is run; for all exception exits from the try block, s/we // +++ gcc/calls.c

Re: Mark objects death at end of scope

2011-11-03 Thread Michael Matz
Hi, On Thu, 3 Nov 2011, Richard Guenther wrote: +  /* Add clobbers for all variables that go out of scope.  */ +  for (t = BIND_EXPR_VARS (bind_expr); t ; t = DECL_CHAIN (t)) +    { +      if (TREE_CODE (t) == VAR_DECL +         !is_global_var (t) I think you want to use

Re: Mark objects death at end of scope

2011-11-03 Thread Michael Matz
Hi, On Thu, 3 Nov 2011, Jakub Jelinek wrote: personality. I'm not sure what the best fix here is. The rest of the compiler uses COMPILER and LINKER make variables that are set correctly depending on bootstrap configuration. But the gnattools Makefile.in doesn't know about these, so

Re: Mark objects death at end of scope

2011-11-03 Thread Michael Matz
Hi, On Thu, 3 Nov 2011, Jakub Jelinek wrote: It's possible. At expansion time the clobbers expand to nothing, so those regions theoretically are mergeable with outer regions, but we don't have EH cleanups on RTL anymore. That is unfortunate. Can't EH cleanups be taught about these

Re: Mark objects death at end of scope

2011-11-03 Thread Michael Matz
Hi, On Thu, 3 Nov 2011, Richard Guenther wrote: If gnattools are built with the C++ compiler they should also link with the G++ driver, so that's  worth fixing anyway I think. gnattools is built with the C compiler, but it reuses a couple of object files of libbackend.a that are now

Build gcc/ with -fno-exceptions -fno-rtti

2011-11-03 Thread Michael Matz
Hi, On Thu, 3 Nov 2011, Eric Botcazou wrote: There is a bug about not using -fexceptions (50857). Then let's fix it, as you said there We fail to pass -fno-exceptions -fno-rtti to g++ for stage2 and stage3 building the host binaries. That leads to increased compile-time and possibly

Re: Mark objects death at end of scope

2011-11-03 Thread Michael Matz
Hi, On Thu, 3 Nov 2011, Eric Botcazou wrote: libcpp and libcommon and libcommon-target, the latter are: diagnostic.o pretty-print.o intl.o input.o version.o prefix.o params.o opts.o opts-common.o options.o vec.o hooks.o common/common-targhooks.o target-common.o Doesn't read as if

Re: Build gcc/ with -fno-exceptions -fno-rtti

2011-11-03 Thread Michael Matz
Hi, On Thu, 3 Nov 2011, Eric Botcazou wrote: Thus, ok if it passes some testing. And with PR bootstrap/50857 in the ChangeLog for extra brownie points. r180833. Ciao, Michael.

Mark objects death at end of scope

2011-11-02 Thread Michael Matz
Hi, [Eric, see below for an Ada issue] so, this is a more complete resubmission of an old patch, trying to get it into 4.7. In order not to have to rely on TREE_BLOCK of variables to determine valid sharing (which never really worked that well when all the intermediate code movements that

RE: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs

2011-10-26 Thread Michael Matz
Hi, On Wed, 26 Oct 2011, Jiangning Liu wrote: - - if (LOGICAL_OP_NON_SHORT_CIRCUIT) - { - if (code != orig_code || lhs != orig_lhs || rhs != orig_rhs) - return build2_loc (loc, code, truth_type, lhs, rhs); - return NULL_TREE; - }

Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs

2011-10-26 Thread Michael Matz
Hi, On Wed, 26 Oct 2011, Kai Tietz wrote: Yes, this part introduced different behavior for this small case, int f(char *i, int j) {        if (*i j!=2)                return *i;        else                return j; } Well, as far as I understand C specification and sequence

Re: [cxx-mem-model] Generic atomic functions

2011-10-26 Thread Michael Matz
Hi, On Tue, 25 Oct 2011, Andrew MacLeod wrote: and new generic routines are provided as follows: void __atomic_load (T* object, T* return_value, memory_order m) void __atomic_store (T* object, T* new_value, memory_order m) void __atomic_exchange (T* object, T* new_value, T* return_value,

Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs

2011-10-26 Thread Michael Matz
Hi, On Wed, 26 Oct 2011, Kai Tietz wrote: int f(char *i, int j) {        if (*i j!=2)                return *i;        else                return j; } the case can be produced quite easily. extern int global = 0; if (*a global) ... See? You had to

Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs

2011-10-26 Thread Michael Matz
Hi, On Wed, 26 Oct 2011, Kai Tietz wrote: well, if such a function is used as inline and we know for it that j has value != 2, then we have here a big difference. For your first example, we still have to do the memory access to *i, even if we are not interested in result. Actually we

Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs

2011-10-26 Thread Michael Matz
Hi, On Wed, 26 Oct 2011, Kai Tietz wrote: So you would mean that memory dereferencing shouldn't be considered as side-effect at all? No. I haven't said this at all. Of course it's a side-effect, but we're allowed to remove existing ones (under some circumstances). We're not allowed to

Re: [PATCH, i386]: Use reciprocal sequences for vectorized SFmode division and sqrtf(x) for -ffast-math

2011-10-20 Thread Michael Matz
Hi, On Thu, 20 Oct 2011, Uros Bizjak wrote: This patch builds on recent patch by Michael (that implemented fine-grained control on -mrecip option) and with -ffast-math emits reciprocal sequences with additional NR step for vectorized SFmode division and vectorized sqrtf(x). FWIW, I

Re: [PATCH] Handle COND_EXPR/VEC_COND_EXPR in walk_stmt_load_store_addr_ops and ssa verification

2011-10-14 Thread Michael Matz
Hi, On Fri, 14 Oct 2011, Richard Guenther wrote: But I'm not sure. I think we should delete this check from verify_ssa and instead have a corresponding check in verify_stmts (which already properly walks trees) that for an SSA name we encounter we do have a properly linked use (see

Re: RFC: Add ADD_RESTRICT tree code

2011-10-13 Thread Michael Matz
Hi, On Thu, 13 Oct 2011, Jakub Jelinek wrote: I'd sum up my previous mail as noting that restricted pointers are objects, so restrict is not property of expressions. So e.g. I don't think we should add ADD_RESTRICT (or, at least, not an ADD_RESTRICT with different tag) on every assignment

Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs

2011-10-13 Thread Michael Matz
Hi, On Thu, 13 Oct 2011, Kai Tietz wrote: this new version addresses the comments from Michael and additional fixes an latent issue shown up by this rewrite in fold-const. On gimplify.c's gimple_boolify we didn't handled the case that operands for TRUTH-expressions need to have same

Re: RFC: Add ADD_RESTRICT tree code

2011-10-13 Thread Michael Matz
Hi, On Thu, 13 Oct 2011, Jakub Jelinek wrote: On Thu, Oct 13, 2011 at 02:57:56PM +0200, Michael Matz wrote: struct S {int * restrict p;}; void foo (struct S *s, struct S *t) { s-p[0] = 0; t-p[0] = 1; // undefined if s-p == t-p; the caller was responsible

Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs

2011-10-12 Thread Michael Matz
Hi, On Wed, 12 Oct 2011, Kai Tietz wrote: And I think it could use some overview of the transformation done like in the initial patch, ala: Transform ((A B) C) into (A (B C)). and Or (A B) into (A B). for this part: +     /* Needed for sequence points to handle

Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs

2011-10-12 Thread Michael Matz
Hi, On Wed, 12 Oct 2011, Kai Tietz wrote: Hmm?  What do you mean?  Both operations are binary.  ANDIF is '', AND is ''.  In fold-const.c comments we usually use the C notations of the operations. See TRUTH_AND_EXPR is in C-notation and TRUTH_ANDIF_EXPR is also . Ah right, confusing

Re: [PATCH] Fix PR50204

2011-10-12 Thread Michael Matz
Hi, On Tue, 11 Oct 2011, Richard Guenther wrote: Since we have the alias oracle we no longer optimize the testcase below because I initially restricted the stmt walking to give up for PHIs with more than 2 arguments because of compile-time complexity issues. But it's easy to see that

Re: [PATCH] Fix PR50204

2011-10-12 Thread Michael Matz
Hi, no need to test a phi argument with itself (testing arg0 != arg1 is not the right test, though, so remembering the candidate index): @@ -1948,18 +1958,35 @@ get_continuation_for_phi (gimple phi, ao until we hit the phi argument definition that dominates the other one. */

Re: RFC: Add ADD_RESTRICT tree code

2011-10-12 Thread Michael Matz
Hi, On Wed, 12 Oct 2011, Jakub Jelinek wrote: Assignment 2 means that t-p points to s.p. Assignment 3 changes t-p and s.p, but the change to s.p doesn't occur through a pointer based on t-p or any other restrict pointer, in fact it doesn't occur through any explicit initialization or

Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs

2011-10-11 Thread Michael Matz
Hi, On Mon, 10 Oct 2011, Kai Tietz wrote: To ensure that we use simple_operand_p in all cases, beside for branching AND/OR chains, in same way as before, I added to this function an additional argument, by which the looking into comparisons can be activated. Better make it a separate

Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs

2011-10-11 Thread Michael Matz
Hi, On Tue, 11 Oct 2011, Kai Tietz wrote: Better make it a separate function the first tests your new conditions, and then calls simple_operand_p. Well, either I make it a new function and call it instead of simple_operand_p, That's what I meant, yes. @@ -5149,13 +5176,6 @@

Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs

2011-10-11 Thread Michael Matz
Hi, On Tue, 11 Oct 2011, Kai Tietz wrote: So updated version for patch. It creates new simple_operand_p_2 function instead of modifying simple_operand_p function. FWIW: I also can't think of a nice short name for that predicate function :) One thing: move the test for TREE_SIDE_EFFECTS to

Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs

2011-10-10 Thread Michael Matz
Hi, On Mon, 10 Oct 2011, Kai Tietz wrote: extern int foo (void); /* foo modifies gbl1 */ int gbl1 = 0; int foo (int ns1) { if (ns1 foo () gbl1) return 1; return 0; } so chain of trees has to look like this: (ANDIF (ns1 (ANDIF foo () gbl1)) Okay, indeed. I was wrong when

Re: [RFC] Split -mrecip

2011-10-07 Thread Michael Matz
Hi, On Wed, 5 Oct 2011, Uros Bizjak wrote: Like so.  Currently regstrapping on x86_64-linux.  Okay if that succeeds? OK, with a nit - I'd introduce RECIP_MASK_NONE and use it in place of 0 in a couple of places. Okay. r179608 it is. Ciao, Michael.

Fix PR50638 (segfault with emutls)

2011-10-07 Thread Michael Matz
Hi, tree-emutls.c missed to called add_referenced_var for a variable that is referenced. That always was a bug, but meanwhile is fatal (causing a segfault). This fixes the problem. Okay for trunk if regstrapping succeeds? The related bugreport PR50640 (fortran segfaults for similar

Re: [PATCH 0/3] Fix vector shuffle problems

2011-10-06 Thread Michael Matz
Hi, On Wed, 5 Oct 2011, Richard Henderson wrote: Tested on x86_64 with check-gcc//unix/{,-mssse3,-msse4} Hopefully one of the AMD guys can test on a bulldozer with -mxop? === gcc Summary for unix//-mxop === # of expected passes160 Ciao, Michael.

Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs

2011-10-06 Thread Michael Matz
Hi, On Thu, 6 Oct 2011, Richard Guenther wrote: +       ((TREE_CODE_CLASS (TREE_CODE (arg1)) != tcc_comparison +           TREE_CODE (arg1) != TRUTH_NOT_EXPR) +         || !FLOAT_TYPE_P (TREE_TYPE (TREE_OPERAND (arg1, 0) ? simple_operand_p would have rejected both ! and

Re: rfa: remove get_var_ann (was: Fix PR50260)

2011-10-06 Thread Michael Matz
Hi, On Sat, 3 Sep 2011, Richard Guenther wrote: OTOH it's a nice invariant that can actually be checked for (that all reachable vars whatsoever have to be in referenced_vars), so I'm going to do that. Yes, until we get rid of referenced_vars (which we still should do at some

Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs

2011-10-06 Thread Michael Matz
Hi, On Thu, 6 Oct 2011, Kai Tietz wrote: That's not the hole story. The difference between TRUTH_(AND|OR)IF_EXPR and TRUTH_(AND|OR)_EXPR are, that for TRUTH_(AND|OR)IF_EXPR gimplifier creates a COND expression, but for TRUTH_(AND|OR)_EXPR it doesn't. Yes, of course. That is what

Re: [patch tree-optimization]: Improve handling of conditional-branches on targets with high branch costs

2011-10-06 Thread Michael Matz
Hi, On Thu, 6 Oct 2011, Kai Tietz wrote: at which point this association doesn't make sense anymore, as Sorry, exactly this doesn't happen, due an ANDIF isn't simple, and therefore it isn't transformed into and AND. Right ...  ((W AND X) AND Y) AND Z is just as fine.  So, the

Re: [RFC] Split -mrecip

2011-10-05 Thread Michael Matz
Hi, On Mon, 19 Sep 2011, Uros Bizjak wrote: Looking at this topic again, I'd propose that x86 adopts approach from rs6000. The rs6000 approach is more extensible, and offers the same flexibility, due to !. So, x86 could have -mrecip=opt, with all, default, none, div, vec-div, divf,

Re: [RFC PATCH] restrict_based_on_field attribute

2011-10-04 Thread Michael Matz
Hi, On Mon, 3 Oct 2011, Jakub Jelinek wrote: std::vector acts roughly as something having a restrict pointer field, i.e. two different std::vector objects will have the pointers pointing to a different array, unfortunately unlike e.g. std::valarray we have 3 different pointers pointing into

Re: [RFC PATCH] restrict_based_on_field attribute

2011-10-04 Thread Michael Matz
Hi, On Tue, 4 Oct 2011, Jakub Jelinek wrote: If it causes miscompilations, then GCC is buggy and needs to be fixed. That's not easy without effectively making the whole restrict support ineffective. Keep in mind that the whole current restrict-tag support was designed to support

Re: PR middle-end/48660: Assigning to BLKmode RESULT_DECL

2011-09-08 Thread Michael Matz
Hi, On Thu, 8 Sep 2011, Richard Sandiford wrote: if (TREE_CODE (from) == CALL_EXPR ! aggregate_value_p (from, from) COMPLETE_TYPE_P (TREE_TYPE (from)) TREE_CODE (TYPE_SIZE (TREE_TYPE (from))) == INTEGER_CST ! (((TREE_CODE (to) == VAR_DECL || TREE_CODE (to) ==

Re: [PATCH] Fix Ada bootstrap failure

2011-09-05 Thread Michael Matz
Hi, On Sat, 3 Sep 2011, Richard Guenther wrote: your patch and apply mine entirely, as eliminating alloca (0) early looks a interesting simplification.  What do you think? I'm not sure we want to create a the replacement decl with DECL_SIZE zero though, so I suppose instead of making

Re: rfa: remove get_var_ann (was: Fix PR50260)

2011-09-03 Thread Michael Matz
Hi, On Sat, 3 Sep 2011, Richard Guenther wrote: As I feared the call to get_var_ann in set_is_used right now really is still needed, privatizing it hence isn't that straight forward. After pondering I concluded that it's not necessary to call set_is_used for variables without var

Re: [RFC] Split -mrecip

2011-09-03 Thread Michael Matz
Hi, On Sat, 3 Sep 2011, Uros Bizjak wrote: I've decided to not use four new bits from target_flags, and instead created a new mask (recip_mask).  Four bits would have fit in target bits right now,  but in the future we might want to add more specialization, like modes for which the

Re: [PATCH] Fix Ada bootstrap failure

2011-09-02 Thread Michael Matz
Hi, On Fri, 2 Sep 2011, Robert Dewar wrote: On 9/2/2011 9:16 AM, Richard Guenther wrote: Might be interesting to pursue, but we don't know that the null pointers being dereferenced are in fact the ones returned by alloca. May not be worth the effort. Given the nature of the work-around

Re: [PATCH] Fix Ada bootstrap failure

2011-09-02 Thread Michael Matz
Hi, On Fri, 2 Sep 2011, Arnaud Charlet wrote: Given the nature of the work-around which makes Ada work again it's fairly sure that the Ada frontend does emit accesses to an alloca'ed area of memory even if its size is zero. I.e. definitely a real bug. Well, it's not clear whether it's

Re: Fix PR50260

2011-09-02 Thread Michael Matz
Hi, On Fri, 2 Sep 2011, Richard Guenther wrote: Currently regstrapping on x86_64-linux (without Ada).  Okay for trunk? Ok. Time to make get_var_ann private? Yes. Should the regstrap succeed on x86_64-linux I'll commit this variant of the patch (hunks in tree-flow.h, tree-flow-inline.h

Re: Fix PR50260

2011-09-02 Thread Michael Matz
Hi, On Fri, 2 Sep 2011, Michael Matz wrote: Hi, On Fri, 2 Sep 2011, Richard Guenther wrote: Currently regstrapping on x86_64-linux (without Ada).  Okay for trunk? Ok. Time to make get_var_ann private? Yes. Should the regstrap succeed on x86_64-linux I'll commit this variant

rfa: remove get_var_ann (was: Fix PR50260)

2011-09-02 Thread Michael Matz
Hi, On Fri, 2 Sep 2011, Michael Matz wrote: Ok. Time to make get_var_ann private? As I feared the call to get_var_ann in set_is_used right now really is still needed, privatizing it hence isn't that straight forward. After pondering I concluded that it's not necessary to call

Re: [PATCH] Make vectorizer dumps more comparable

2011-09-01 Thread Michael Matz
Hi, On Thu, 1 Sep 2011, Richard Sandiford wrote: Ira Rosen i...@il.ibm.com writes: How about, as Micha suggested, print the location of the loop we currently investigate from vectorize_loops () where we call find_loop_location () instead? The problem is that a dump of a single loop

[RFC] Split -mrecip

2011-08-31 Thread Michael Matz
Hello, I'd like to have tighter control over the individual situations that -mrecip handles, and I think the user might appreciate this too. Hence I've introduced four new target options -mrecip-div, -mrecip-sqrt, -mrecip-vec-div and -mrecip-vec-sqrt. I've redefined -mrecip to be equivalent

Re: [lto] Refactor streamer (1/N) (issue4809083)

2011-08-26 Thread Michael Matz
Hi, On Fri, 26 Aug 2011, Richard Guenther wrote: I am going to be sending the renaming patch later today or tomorrow. In principle, the things I want to abstract are those that are forcing me to include lto-streamer.h from {tree,gimple,data}-streamer.*. I will know better when I merge

Re: [lto] Refactor streamer (1/N) (issue4809083)

2011-08-26 Thread Michael Matz
Hi, On Fri, 26 Aug 2011, Jakub Jelinek wrote: While you are touching it, I think we should also optimize it as in the patch below. I'm afraid no string length optimization would be able to figure out that it doesn't have to call strlen twice, because the htab_find_slot isn't pure. Sure.

Re: [PATCH] Make vectorizer dumps more comparable

2011-08-24 Thread Michael Matz
Hi, On Wed, 24 Aug 2011, Richard Guenther wrote: This avoids the file/location clutter in front of each line in the vectorizer dump. While this is useful for people requesting -fvectorizer-verbose=N in dump files this makes you unable to compare dumps for testcases on a branch and trunk.

Re: [google] Remove timestamped line from gengtype state file comment headers

2011-08-23 Thread Michael Matz
Hi, On Tue, 23 Aug 2011, Richard Guenther wrote: This patch removes the comment line, to provide binary reproducibility for any generated gtype.state files. Tested for x86 and PowerPC, no bootstrap in both cases. OK for google/integration?  Also, OK for trunk? Ok for trunk. But

Re: [rfa] Set alignment of pseudos via get_pointer_alignment

2011-08-23 Thread Michael Matz
Hi, Like so.  Regstrapped on x86_64-linux (all languages + Ada).  Okay for trunk? Ok. r177989 (JFYI because it's some time ago to make searching the archives easier). Ciao, Michael.

Re: [4.7][google]Support for getting CPU type and feature information at run-time. (issue4893046)

2011-08-22 Thread Michael Matz
Hi, On Sun, 21 Aug 2011, Richard Guenther wrote: On Sat, Aug 20, 2011 at 11:02 PM, Richard Henderson r...@redhat.com wrote: On 08/19/2011 02:04 AM, Richard Guenther wrote: So make sure that __cpu_indicator initially has a conservative correct value?  I'd still prefer the

Re: mem_attrs_htab

2011-08-22 Thread Michael Matz
Hi, On Mon, 22 Aug 2011, Richard Guenther wrote: Some functions are extremely large though.  Do you mean that MEM itself would be enlarged to have the MEM_ATTRS field so that one operand is the address, then expr, then HWI size, offset, etc.?  Because if the mem attrs aren't shared

Re: [4.7][google]Support for getting CPU type and feature information at run-time. (issue4893046)

2011-08-22 Thread Michael Matz
Hi, On Mon, 22 Aug 2011, H.J. Lu wrote: Oh, I thought it was data initialized by the constructor ... Sriramans patch right now has a function __cpu_indicator_init which is called from (adhoc constructed) ctors and that initializes variables __cpu_model and __cpu_features ;-)  There's

Re: C1X Unicode strings without raw strings

2011-08-18 Thread Michael Matz
Hi, On Thu, 18 Aug 2011, Joseph S. Myers wrote: @@ -315,6 +315,10 @@ struct cpp_options /* Nonzero means process u/U prefix literals (UTF-16/32). */ unsigned char uliterals; + /* Nonzero means process r/R rax strings. If this is set, uliterals + must be set as well. */ +

Re: [PATCH 2/2] document ISL requirement for GCC installation

2011-08-15 Thread Michael Matz
Hi, On Sun, 14 Aug 2011, Richard Guenther wrote: which would be exactly the way no distribution would use it. So please just don't bundle ISL with CLoog. Well, I would simply have linked the bundled ISL statically into libcloog. Which would still require not exporting the (bundled)

Re: [PATCH, i386]: Expand round(a) = sgn(a) * floor(fabs(a) + 0.5) using SSE4 ROUND insn

2011-08-15 Thread Michael Matz
Hi, On Mon, 15 Aug 2011, Richard Guenther wrote: Adding -msse4, we now generate branchless code using roundsd: .LFB0:        .cfi_startproc        movsd   .LC0(%rip), %xmm2        movapd  %xmm0, %xmm1        andpd   %xmm2, %xmm1        andnpd  %xmm0, %xmm2        addsd  

Re: [PATCH, i386]: Expand round(a) = sgn(a) * floor(fabs(a) + 0.5) using SSE4 ROUND insn

2011-08-15 Thread Michael Matz
Hi, On Mon, 15 Aug 2011, Michael Matz wrote: .LFB0:        .cfi_startproc        movsd   .LC0(%rip), %xmm2        movapd  %xmm0, %xmm1        andpd   %xmm2, %xmm1        andnpd  %xmm0, %xmm2        addsd   .LC1(%rip), %xmm1        roundsd $1, %xmm1, %xmm1        orpd

Re: [lto] Rename functions in tree/data streamer (issue4886041)

2011-08-12 Thread Michael Matz
Hi, On Fri, 12 Aug 2011, Diego Novillo wrote: 3- Replaces dwarf terminology for numbers with C-like terminology: sleb128 - wide_int uleb128 - wide_uint I see downthread that this is changed to hwi/uhwi already. I even would have suggested int/uint directly, as we never stream

[rfa] Set alignment of pseudos via get_pointer_alignment

2011-08-12 Thread Michael Matz
Hi, On Tue, 9 Aug 2011, Michael Matz wrote: Are there any updates on the libada problem or other reasons why the patch cannot go in? Nope, I've solved that one. Letme update it. Like so. Regstrapped on x86_64-linux (all languages + Ada). Okay for trunk? Ciao, Michael

Re: [lto] Remove most streamer hooks. (issue4863041)

2011-08-11 Thread Michael Matz
Hi, On Wed, 10 Aug 2011, Diego Novillo wrote: The API in the tree streamer offers functions to read/write the tree header and the body, a streamer cache and everything that used to be inside the LTO streamer. This makes no difference to LTO, since it simply means that some

Re: Merge alignments from coalesced SSA pointers

2011-08-09 Thread Michael Matz
Hi, On Mon, 8 Aug 2011, Ulrich Weigand wrote: This patch exposes a problem in libada. But I'd still be interested if it fixes the spu problem. It turns out that the patch not only fixes the pr49771 failure, but in fact *all* outstanding vectorizer test case failures on SPU in both

Re: [PATCH] Extend VRP BIT_IOR_EXPR to handle sign-bit

2011-08-09 Thread Michael Matz
Hi, On Tue, 9 Aug 2011, Richard Guenther wrote: Actually we should adjust the ranges only if it's either all positive or negative values from the start and the adjustment keeps us on the same side of zero. So we kept discussing this to death somewhat. Which eventually resulted in

Re: [lto] Refactor streamer (1/N) (issue4809083)

2011-08-08 Thread Michael Matz
Hi, On Mon, 8 Aug 2011, Diego Novillo wrote: With these patches I'd like to: 1 Create independent facilities to stream trees, gimple and other data structures independently of LTO. This first patch creates the files data-streamer*.[ch], tree-streamer*.[ch] and

Re: [patch tree-optimization]: Improve reassociation pass for bitwise-operations

2011-08-04 Thread Michael Matz
Hi, On Wed, 3 Aug 2011, Kai Tietz wrote: This machinery doen't work in this case That's why you have to extend it. The issue about this machinery is that it assumes that the statement itself gets transformed, but for normalized form of invert of bitwise operations it is essential to

Re: [patch tree-optimization]: Improve reassociation pass for bitwise-operations

2011-08-03 Thread Michael Matz
Hi, On Tue, 2 Aug 2011, Kai Tietz wrote: this patch improves the ability of reassociation pass to simplifiy more complex bitwise-binary operations with comparisons. We break-up for this patch statements like (X | Y) != 0 to X != 0 | Y != 0, and (X | Y) == 0 to expanded X == 0 Y == 0.

Re: [patch tree-optimization]: Improve reassociation pass for bitwise-operations

2011-08-03 Thread Michael Matz
Hi, On Wed, 3 Aug 2011, Kai Tietz wrote: Implement all of this in the normal reassoc machinery that already exists. Don't implement your own walker (which btw is superlinear because you recurse into both operands).  If no simplifications were possible you have to fold back the NOTs

Re: [PATCH PR43513, 1/3] Replace vla with array - Implementation.

2011-07-27 Thread Michael Matz
Hi, On Wed, 27 Jul 2011, Richard Guenther wrote: I don't think it is safe to try to get at the VLA type the way you do. I don't understand in what way it's not safe. Do you mean I don't manage to find the type always, or that I find the wrong type, or something else? I think you

<    2   3   4   5   6   7   8   >